Hi, folks!

I'm facing a performance issue in my aplication. By activating "Debug Mode", it shows:
Trigger 0.000 seconds (+0.000); 0.00 MB (0.000) - postAppInitialise
Trigger 0.008 seconds (+0.008); 0.22 MB (+0.219) - postAppEcommerce
Trigger 0.010 seconds (+0.002); 0.32 MB (+0.099) - postAppRoute
Trigger 0.011 seconds (+0.001); 0.36 MB (+0.038) - preLoadController
Trigger 0.012 seconds (+0.001); 0.38 MB (+0.022) - preLoadModel
Trigger 0.013 seconds (+0.001); 0.39 MB (+0.010) - postLoadModel
Trigger 0.015 seconds (+0.002); 0.42 MB (+0.029) - preLoadLanguage
Trigger 0.016 seconds (+0.001); 0.42 MB (+0.003) - postLoadLanguage
Trigger 0.024 seconds (+0.008); 0.66 MB (+0.246) - preLoadView
Trigger 0.025 seconds (+0.001); 0.67 MB (+0.007) - postLoadView
Trigger 0.025 seconds (+0.001); 0.62 MB (-0.048) - postLoadController
Trigger 11.869 seconds (+11.843); 1.30 MB (+0.673) - preCatalogLayoutPosition <--- HERE
Trigger 13.096 seconds (+1.228); 1.37 MB (+0.071) - postAppDispatch
Trigger 13.101 seconds (+0.005); 1.37 MB (+0.000) - postAppRender

As you can see, by what I understood, preCatalogLayoutPosition event is being triggered about 11 seconds after previous event. What can be happening between postLoadController and preCatalogLayoutPosition that is taking too much time?
Denis, Rune, Cüneyt, Burak, someone, any help is appreciated.
thank you in advance!
In General
Friday, June 24 2016, 05:06 PM
Share this post:
Responses (7)
  • Accepted Answer

    Saturday, June 25 2016, 12:37 PM - #Permalink
    Gedielson, which page are loading? Home, category, product?
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 25 2016, 04:46 PM - #Permalink
    Hi, Denis.
    Thank you for your reply.
    Is the home page. But I got it!
    I modified the debug tool in order to show ALL the triggered events on page loading, not only the distinct ones.
    I have a custom function that uses CURL, and I found through the triggered events waterfall that this function was slowing down page load time.
    So I improved the performance of this function and solved the issue.
    Man, Arastta's debug tool is f*** awesome! It's perfect to see where the logic is spending more load time!
    Thank you again!
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, June 25 2016, 05:25 PM - #Permalink
    Glad to see you've solved it Gedielson. Would you consider to contribute your modification to the core via GitHub?
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, June 26 2016, 02:01 AM - #Permalink
    Yes, I can do this. But one of the modified files is in vendor/joomla folder, which isn't in repository. How to proceed with this file?
    The reply is currently minimized Show
  • Accepted Answer

    Monday, June 27 2016, 12:39 PM - #Permalink
    Well, that is not possible Gedielson as it's a 3rd party library :(
    The reply is currently minimized Show
  • Accepted Answer

    Monday, October 10 2016, 05:09 PM - #Permalink
    Hi, I got the same problem with slow triggered event. Would be nice if Gedielson would char the solution.

    Kind regards

    Hermann
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, October 12 2016, 09:14 PM - #Permalink
    Hi, Herman.
    As I said, the issue was with one of my custom functions, that I've added to the core code.
    I opened the file in system/vendor/joomla/profiler/src/Profiler.php, and in the mark($name) function, just comment the following code:
    if (isset($this->lookup[$name]))
    {
    throw new \InvalidArgumentException(
    sprintf(
    'A point already exists with the name %s in the profiler %s.',
    $name,
    $this->name
    )
    );
    }

    This will make profiler to point ALL the triggered events, not only the distinct ones. This way, you can follow the events waterfall and check which of the events is spending more time to load.
    The reply is currently minimized Show
Your Reply