Opened 10 years ago

Last modified 36 hours ago

#5582 assigned bug

[AboutSystem] is slow to appear

Reported by: diver Owned by: nobody
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (3)

AboutSystem-profile.txt (88.9 KB ) - added by bonefish 10 years ago.
output of "profile -f -i100 AboutSystem"
AboutSystem-profile-VirtualBox.txt (133.5 KB ) - added by diver 10 years ago.
AboutSystem-locale-profile-VirtualBox.txt (132.5 KB ) - added by diver 10 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by diver, 10 years ago

It takes:

to start AboutSystem/Terminal in VirtualBox.

comment:2 by bonefish, 10 years ago

Owner: changed from bonefish to nobody
Status: newassigned

by bonefish, 10 years ago

Attachment: AboutSystem-profile.txt added

output of "profile -f -i100 AboutSystem"

comment:3 by bonefish, 10 years ago

Component: Applications/AboutSystemKits/Interface Kit
Version: R1/alpha1R1/Development

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.

comment:4 by diver, 10 years ago

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

comment:5 by diver, 10 years ago

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?

comment:6 by stippi, 10 years ago

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... :-)

comment:7 by diver, 14 months ago

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.

comment:8 by pulkomandy, 36 hours ago

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.

Note: See TracTickets for help on using tickets.