Open morvy opened 1 month ago
Interesting, I have not noticed this, but then again I have not been paying attention to performance.
I will be running some profiling myself but it seems like if the issue is with cooked/vendor/composer/ClassLoader.php
than it has to be related to either Composer in general or the nxp/math-executor
package. That is the only reason why composer is even being used in the first place.
If this is really the problem, it would be possible to manually include the nxp/math-executor
library without using a dynamic class loader. This should fix the issue but it does introduce the problem of maintaining updates for the nxp/math-executor
library.
It might also be possible to just set the correct composer settings such as "optimize-autoloader": true
as documented here: https://getcomposer.org/doc/articles/autoloader-optimization.md
And then reinstalling the package using composer install or update --optimize-autoloader
I've added the optimize-autoloader, dump-autoload -o and uploaded. The site crashed, because math-executor is not very nice about versioning :) 2.3.2 is compatible with PHP7.4, 2.3.3 with 8.0. Such breaking change shouldn't be a patch version. So I restricted the library to 2.3.2 as I cannot upgrade PHP on this specific site. Optimized autoloader helped a bit, now it's down to 0.64s but it's still a lot.
I'm wondering if it's just the nxp/math-executor
library that is causing this. Can you possibly try to remove the dependency on that and run the profiler again?
Basically just comment out the:
require_once __DIR__ . '/vendor/autoload.php';
In line # 31 in wp-content/plugins/cooked/cooked.php
And in wp-content/plugins/cooked/includes/class.cooked-measurements.php
comment out:
Line # 13
use NXP\MathExecutor;
And Line # 496 & # 470
$mathExecutor = new MathExecutor();
$o = $mathExecutor->execute($expression);
I am trying to profile the code myself but I am not able to see what you are seeing. What page in the admin side are you using for the profiling?
Well, without nxp, the load time went down to 0.01s.
Is it used for calculating ingredients when you change yields? If the functionality is not used, it would be great to skip whole loading of the library, at least with a wp-config constant or a hook. I understand some people still need it, but on my site it's not used and removing it helped a lot.
Regarding the page I test against, I test it on "Recipes" frontend page, "Blog" frontend page, "Posts" backend page and "Dashboard" backend page. Code Profiler Pro marks it as most demanding on all pages, but after removing the math-executor, the whole site is faster. I have to note, that CPP shows only plugins that use composer, so some parts I also measure with php x-ray (frontend, without cache). I'm not a pro with these debugging and profiling tools, so I may be wrong. I still feel the page is not as fast as before, so I'll create a dev and try to disabled Cooked and Cooked Pro to see the difference in xdebug on my local machine.
Thanks
Yeah I suspected it to be the issue but was not sure. In that case I'm going to see what can be done about it. Like you said, either deferring the loading of the library somehow or some other solution.
Since installing Cooked, the page load times have doubled on my site. It's fine when the content is cached, but admin is not cached and is much slower. As soon as I disable Cooked, admin is as fast as before. I also checked the performance with Code Profiler Pro and it shows Cooked to take more time to load classes than WooCommerce, Yoast and WP Rocket combined.
/wp-content/plugins/cooked/vendor/composer/ClassLoader.php
takes 0.78s to load, while Woo takes only 0.15s.