I’ve created an issue on GitHub.
Is there a workaround possible, till this issue is solved?
call_user_func_array seems to be slow when called often or with too many arguments. one could refactor the function toolkit/helper/call() to use argument unpacking (since php 5.6). so instead of call_user_func_array use something like that:
$object->{$method}(...$args);
or when no object available
$method(...$args);I tried this before, but it changed nothing. It stays slow as it was before.
then refactor panel/models/page/removeThumbs() to not clean folder but check for timestamp of all thumb-files if page panel/models/page/replace() and upload() where called. if move() was called it needs to remove all.
Unfortunately I can’t reproduce this issue. I have tried generating several thumbs of an image. First page load takes around 3 seconds, every following page load around 3 milliseconds.
@robert @Andi-Lo Do you have a simple test-case based on the starterkit that is able to reproduce this issue?
@lukasbestle drop me a pm and we discuss things further.
Feel free to send me one with more information. You can also drop me an email at lukas@getkirby. Thanks. 
@lukasbestle As you mentioned, the first load took “3 seconds”, the following page load around “3 milliseconds”. When you wait a while (a longer period), the next page load again lasts “3 seconds” - then the next page load “3 milliseconds” - and so on. (The “seconds” depends on the host, which is running the scripts)
After a hint in another post (Super slow frontend and panel not loading at all), I changed von PHP 7 back to 5.6 and activated fast-cgi.
This helped in that way, that the (first) load of the pictures lasts only a tenth of the time required before. But the first load of one (!) picture (of a dozen on this page) requires still approx. 500 milliseconds.
@robert:
Are you sure, that the PHP process runs 24 h a day?
On some cheap installations, the PHP process dies after some time of not running. The PHP process then needs to start for the “first” webpage, what needs some time. The next webpage is very much faster…
What @anon77445132 wrote is correct. Starting up a PHP worker takes a lot of time (a few seconds), so if there is none because there haven’t been requests in a while, it’s normal for the first page load to be slower. And because that startup time is spent before Kirby is even loaded, we can’t do anything against that.
What you could try to verify if this worker timeout is the issue:
- Load a page with many thumbs, note down the response time.
- Load the page again, note down the response time.
- Wait for a “longer period”.
- Load a page that doesn’t have any thumbs and note down the response time.
If the page without thumbs takes long to load as well, it can’t be related to thumbs.
1 Like
@lukasbestle @anon77445132 No, it’s not the starting up of a PHP worker:
The concrete website is hosted at a provider and starts with a login-page - without any image. This login-page comes as fast as it should. The website is a gallery of a approx. hundred of images. This gallery is paginated, so that on every page a dozen of images are shown. The long loads are on every new (paginated) page. When a page is reloaded the loads are very quick.
To mention it explicit: The load times are measured on server side.
1 Like
@robert:
Does the website or your hoster use any cache or CDN?
Does your browser use any add-in that shows something like a cache?
Have you changed your /site/config/config.php to use the Kirby cache or another cache or CDN?
Answer to all questions: No
The only cache that’s enabled is the opcache-module of PHP.
I would look at the …
May be, stop the opcache-module for a test and look for your error, is this error gone?
Thanks for the details. I agree that it can’t be the worker processes then. I’d also rule out the OpCache as that only caches the code files, not any type of generated content.
But the issue is still strange. I don’t know where to start debugging as I can’t reproduce it. 
@anon77445132 Deactivating the opcache-module results only in slower overall performance of execution of kirby.
@lukasbestle As mentioned in my post from 2017-01-30 there seems to be a problem with the execution of call_user_func_array($function, $arguments) in toolkit/helpers.php. The calls results in slow “first time execution” for the image-objects. Maybe this is an PHP-internal effect?!
Theoretically, the execution of call_user_func_array() was optimized in PHP7, but in this case it is not faster.
As I have not enough PHP-knowledge, I’m not able to further investigate the specific calls, which are executed during getting/preparing an image.
1 Like
I can’t be call_user_func_array(), especially not because we use this function (with Kirby’s call() helper) a lot, not only for thumbs.
But of course call_user_func_array() calls a function and that function might/will be the bottleneck (or some other function that is called by that function). However we don’t know where to start debugging if we can’t reproduce the issue.
@lukasbestle Is there a way to produce a log (including timing) with “all” inner-calls for call_user_func_array()? I’m not that familiar with PHP, so I need assistance to do that. After that I can give you the resulting log-file.
That’s a good idea. You can use Xdebug’s Profiler for this.