[AboutSystem] is slow to appear

[diver]

It is much more visible in VirtualBox where it takes up to 3 second to start. On real hw it almost instant, but you could see that right textview is white for a half of second. AboutSystem starts fast in hrev30012 in VirtualBox. BTW same goes to Terminal which on current images takes 3 second to launch, but almost instant in hrev30012. All other apps are starting much faster, even such big app like WebPositive is starting faster than AboutSystem and Terminal.

[diver]

It takes:

• 1 sec in hrev30012
• 2 sec in hrev33019
• 3 sec in hrev35884

to start AboutSystem/Terminal in VirtualBox.

[bonefish]

output of "profile -f -i100 AboutSystem"

[bonefish]

Added "profile" output taken in qemu (i.e. take with a grain of salt). From a quick look BTextView methods are the ones consuming a good deal of the time. That would also explain why things got gradually slower -- the amount of text in the text view has been getting more and more. profile's cachegrind output will allow for a better analysis, though.

[diver]

I could be wrong, but I think that with locale set to some language it's even slower.

[diver]

More stuff became slower in vbox recently, basically everything Locale related (e.g. Locale, Time). Localized apps feel slower too. Should I open new ticket or we don't care about Haiku performance in VirtualBox?

[stippi]

The slowdown is indeed annoying and also noticeable on real hardware. The work on the Locale Kit should definitely be rounded up by an aggressive profiling and optimization phase... :-)

[diver]

It takes 1 second now in VMware (hrev53129) with a speedy CPU. Still, too long for such a little app. And since I don't remember if there were any optimizations in Locale Kit I'm leaving it open.

[pulkomandy]

Apparently I never commented here. There are various things I can think of in the locale kit that could be slow, unfortunately, I don't know how to improve them without removing functionalities or changing APIs.

Catalog loading:

The locale kit looks in several places for catalogs. I think we removed loading them from attributes, but it looks in the application resources, and then in the packaged and non-packaged, user and system directories. Of course for system apps the catalogs are in packaged-system, which is the last place looked at (this allows testing catalogs that are not installed with the OS). Maybe we could stop looking in user/ for apps installed in system/ ?

String lookup: Catalogs store strings in a hash map, with the key being the english string and context. This means the lookup for a string is done as follows:

• 1) compute the hash from the original string and context
• 2) search the hashmap for a matching hash
• 3) compare the string and context from the matching entry with the initial ones to make sure there is no conflict
• 4) finally, get the translated string

Steps 1-3 could be removed if the key was an integer, with no risk of conflict. Doing this requires an ABI change, which is that B_TRANSLATE would parse its argument at compile-time and somehow replace it with an integer key for it.

ICU data loading:

ICU data is currently a .so file. I think it is loaded from disk (using dlopen()) in each app using ICU. Ideally, this data would be loaded only once and shared between all applications. This probably requires changes in ICU, or maybe in the locale kit at least, to tell ICU where to look for the data (maybe using a segment of shared memory for it). Normally this data is loaded on-demand, but in the case of AboutSystem, it will be needed for example to format the uptime string.

While working on this, we should also switch to using a .dat file instead of a .so, allowing the reuse of the data between multiple gcc versions. However, I'm not sure we can do this with different ICU versions, and newer versions won't build with gcc8.

[pulkomandy]

Fixed in hrev54493.

[KapiX]

Fix was reverted in hrev54530.

[jscipione]

Fixed again in hrev54549.