So I kept profiling m-m today.
I found that g_get_language_names called g_getenv a lot, which in turn calls getenv. This account for ~5% of the startup time of m-m as seen below;
Since I know that Michael Meeks came to this same conclusion in his blog about gnome-menus, I decided to run a quick test with gnome-menu-spec-test. The result is this;
Having a look at g_get_language_names I found that it does have a cache for language names, but it didn’t seem to be used efficiently. Now, I don’t know if there is a reason to find out if the language has changed while a program is running, but for the life of me, I can’t think of one.
Here’s a small snippet of the code;
if (!cache)
{
cache = g_new0 (GLanguageNamesCache, 1);
g_static_private_set (&cache_private, cache, language_names_cache_free);
}
value = guess_category_value ("LC_MESSAGES");
if (!value)
value = "C";
if (!(cache->languages && strcmp (cache->languages, value) == 0))
{
gchar **languages;
gchar **alist, **a;
It checks to see if it cached the language and if it did, retrieve the cache. Then it goes to check the language variables (no matter if it had a cache or not). I made a simple code change to NOT check the variables if the cache exists. Since I’ve never looked at the glib2 code before, I don’t know if the patch is sane, so I’ve asked for a review. But the cache here is per application, so changing the environment variables and starting a new application will work.
Result of the code change is this for m-m;
And this for gnome-menus;
