Looks OK here.

BTW this also saves 1.2 ms (of a total page generate of 137.15 ms) during JApplicationSite::initializeApp, ie, all site pages (in my php7 multilingual site).

Before

After

If you want to make this performance test, enable debug system plugin and in https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/site.php#L582 add

    protected function initialiseApp($options = array())
    {
        // [Code removed for brevity]

        if (JPluginHelper::isEnabled('system', 'languagefilter'))
        {
            // [Code removed for brevity]
        }

        !JDEBUG ?: $this->profiler->mark('-> initialiseSiteApp (languages part) START');

        // [Code removed for brevity]

        !JDEBUG ?: $this->profiler->mark('-> initialiseSiteApp (languages part) END');

        // Finish initialisation
        parent::initialiseApp($options);
    }

@andrepereiradasilva - I don't see how changing the function name would yield any performance improvement. 1.2ms is negligible and most probably due to other processes running on your pc. At the end it is the same function just in another class.

then try it yourself

1.2ms is negligible and most probably

"negligible", well it depends. when your all site loads in 130ms (like mine does), it's almosts 1% of the total ... so do 100 performance improvements like this one and you get a total server page generation time of 1ms ? .

so you don't think i'm crazy

This is my start page in 3 languages multilingual joomla latest staging install with php7 WITHOUT opcache (with patch applied)

Okay, I take it back. It seems that it really improves performance.

Any ideas why this is actually happening? What's the hidden PHP optimization that we are hitting with that?

First, let me say i'm not a full time PHP developer (it's more like an hobby in my case) so i could be wrong here.

So, taking this case as an example, i guess that since we are now directly calling the JLanguageHelper class, php doesn't need to instanciate the whole JLanguage class to perform this particular operation that in reality does not depend on JLanguage class methods or properties. So, probably, that's why we have a slight performance/memory usage improvement.

Since i noticed the joomla framework is in the process of doing the same for this and other JLanguage methods (https://github.com/joomla-framework/language/blob/2.0-dev/src/LanguageHelper.php#L30), for sure @mbabker can explain better than i do why this slight performance/memory usage improvement happens.

I thought the same, but isn't the JLanguage class going to be called at a later stage, because joomla needs it for the language anyway. So the seconds gained at this stage had to be lost later when the jlanguage class is initialised. As you can see from the total before and after - this doesn't seem to be the case. So, I doubt that this is what's going on here.

I think the current selected JLanguage instance is created exactly after this code in the parent JApplicationCms::initialiseApp method.

See https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/cms.php#L638

i did some test and it seems you're right in the first place, there is no significant change. After this patch, the performance and memory usage is more or less transfered to JApplicationCms::initialiseApp JLanguage::getInstance method.

Before patch

After patch

Really the only performance benefit here is when using the method without having a JLanguage instance already instantiated into memory. Which from an architecture standpoint is pretty good, but when it comes to the overall performance of the application and its handling of the request, nobody's going to notice the difference because so many of the global services are instantiated and in use before you even get to the first plugin event (by the time onAfterInitialise triggers, you've already got JSession running with the session started, your database connection open because of the app's checkSession() method or having read your session data into memory on the default configuration, an open connection to the cache storage adapter, the global JLanguage instance with correct language configured, among others; this gist is a snapshot of everything that's loaded by that point from a few months ago).

It's one of those good micro optimizations, but the way the CMS is structured right now it's one that is negligible at best.

ok, i understood. From an architecture standpoint it makes sense but will not have a performance benefit because JLanguage is always loaded in the app.

Anyway, do you have plans for the CMS to start using Language and LanguageHelper from the framework just like we use, for instance, ArrayHelper now?

I have no idea what to do about that. The Framework's Language package has changes that make using it in the CMS less favorable, like not supporting loading files from multiple applications (the JLanguage constructor has path lookups for JPATH_SITE and JPATH_ADMINISTRATOR while the Framework only supports JPATH_ROOT in v1 and requires a base path to be injected in v2). Until the CMS has proper service driven architecture there's probably a slim chance if any to ever use the Framework package.

ok, i see, so 5.0 maybe ;)
thanks again for your help and explanations michael.

I have tested this item ✅ successfully on 7fca933

Works for me navigating to the frontend and backend as well as in different langauges. Thanks.