On Wed, 2014-04-16 at 07:38 +0200, Martin Pitt wrote: > It's not all that obvious really. You only pay the extra price for > mmapping the .mo file once, and as soon as your application/scope has > a single human readable string outside of the .ini file you are going > to pay it anyway. And that price is very low -- on the SD/SSD-like > cards that we have in phones you won't be able to tell the difference.
Not exactly. If you've got 200 applications installed, the click scope has to mmap the current locale's .mo for every single one of those applications (assuming translations are all in the .mo and no inlined translations). So, that's > 200 .mo files that must be loaded by the click scope (because the scope's .mo itself will be loaded, as well as any for other libraries being used by the scope). Some of those applications might have thousands of strings translated, which can make for some very large .mo files, especially in multi-byte locales. It's also quite a lot of disk access, as there will be stat() calls to see if the .mo is there and readable, and to fall back to other languages (such as pt if pt_BR isn't found), as well as having to load the .desktop files themselves and parse them to get the original string, and the gettext domain. For 200 applications installed, that can very easily end up being well over 1000 disk IO hits. Loading only the .desktop file for inline translations means close to, if not, an order of magnitude less disk IO to read the strings, as we're looping over the directory listing, and just loading all the .desktop files, and can fall back to other locales internally, without having to hit the disk to check for additional translations. So it seems to me that inline translations is an obvious and significant performance win there. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
