That looks strange indeed, it should not do anything on the frontend. Is it this plugin you tested with:
https://wordpress.org/plugins/code-profiler/
?
I need to see if I can understand or see how it measures and calculates this.
Thread Starter
bhkh
(@bhkh)
Oh, wow. Thanks for the fast response.
Yes, that’s the one.
I tried another page and SH was not so high. But it’s odd that it appears on the front end at all. Here is the profiler specs and the result:
https://imgur.com/a/pmpzXG5
Let me know if you need more. BTW, the reason Ninja Forms is so high is because it is the first plugin to load the composer.
It may add an admin bar item, if you have not disabled that in the settings page. But that should be very quick, since it’s only adding a text item (the log is loaded first when you hover the item).
If you have the SH admin bar item enabled, you could try to disable it in the admin and see if that makes a different.
Thread Starter
bhkh
(@bhkh)
That feature isn’t enabled. Also, I had ticked the profile setting of “Unauthenticated user” and I believe that tests as a logged out user.
I’ve been looking at this a bit more, even bought the pro version of the code profiler to get some more details. It’s a nice plugin that did give me some hints on what
functions to take an extra look at. I’m not sure however that I can trust it fully when it comes to its reports. It’s using PHP “ticks” to measure performance and I’m not sure exactly how it works but it’s not as accurate as for example Xdebug is.
I used Xdebug on my local test site and the functions that Code Profiler said were slow were very fast according to the XDebug results. For example, it says that my on_gettext() hooks are slow but in Xdebug they show close to 0 execution time. The problem seems to be (after chatting with Claude
about this..) that my plugin registers a hook that runs many times, very fast, making the tick-based profiler not fully understand or time the function correctly.
The technical explanation: (according to Claude):
Code Profiler uses statistical sampling via PHP ticks, which triggers a measurement every N statements. The crucial issue is that it attributes the time between ticks to the
previous code that was executing, not the current code. Since Simple History registers many hooks (especially the gettext filters that run on every translation), it gets sampled frequently. But the actual slowness from other operations gets incorrectly attributed to Simple History because of this attribution lag.
What this means:
- Simple History appears slow in Code Profiler because it’s being “blamed” for time spent in other code
- The gettext filters especially trigger this because they run thousands of times per page load (for every translated string in WordPress)
- XDebug shows the real execution time because it tracks actual function entry/exit, not statistical samples
I’ll will try to reduce the number of gettext calls to minimize the reported slow performance in the Code Profiler plugin + possible other improvements. But even without this I believe the plugin to still be fast 🙂
Thread Starter
bhkh
(@bhkh)
Thank you so much for looking into this. I trust your judgement. I will continue using your plugin happily. Thanks!
I came here to say the same thing. My site is running pretty slow right now and Simple History is the #1 reason according to Code Profiler. The “Simple_History\Loggers\Plugin_Logger->on_gettext” and “Simple_History\Loggers\Plugin_Logger->on_gettext_detect_plugin_error_deactivation_reason” functions are the top two culprits. And as the previous person mentioned, this is running the test as an unauthenticated user without an admin bar menu item.
-
This reply was modified 7 months, 1 week ago by
3yq9nfgnvh.
Thanks for the report @3yq9nfgnvh . While I still don’t believe the code is slow, I will make an effort to minimize the number of issues that code profiler see, no matter the reason.
The author of Code Profiler also wrote a little bit about this in another support thread:
https://wordpress.org/support/topic/clarification-on-how-reliable-the-results-are/
Hi Pär,
I did some performance testing as well and noticed that currently the Simple History adminbar widget appears to load the (full?) React environment for display. This will add about 2MB of code to each request. This might be something to look at as well if possible.
On my test site:
SH active: 4.7MB request size
SH inactive: 2.6MB request size
Thank you and best,
Olivier
@litemotiv thanks for the report. You’re right, it seems that the admin bar function also enqueues some of the WordPress built in JS libraries when active. I only looked at the Simple History admin bar JS file when developing, and that is not that big. I’ll see what I can do to make it not load all that other files too.
There is an update now where I refactored the way the plugin uses gettext() functions. While it won’t make the plugin noticeable faster (since the calls was already very fast) it will make the plugin cal the gettext filter much fewer times. On a regular time before this version gettext could be called maybe ~900 times but after this update the filter is only used on demand, on pages where it’s needed. So on a page where Simple History does nothing now there are 0 gettext filters/calls!
