Language packs and desktop entries

[Alexander Larsson]

On Wed, 2005-06-08 at 16:21 +0900, Takao Fujiwara - Tokyo S/W Center
wrote:
> 
> Alexander Larsson wrote:
> > On Wed, 2005-06-08 at 15:33 +0900, Takao Fujiwara - Tokyo S/W Center
> > wrote:
> > 
> >>Excellent summary. Thanks for the valuable discussions.
> >>
> >>Mark McLoughlin wrote:
> >>
> >>>Hey,
> >>>	To summarise the discussion we had at GUADEC around this issue, we
> >>>talked about two solutions.
> >>>
> >>>  1) Put the translation domain for the app in the .desktop file and
> >>>     have .desktop file parsers pull the translations from the 
> >>>     approriate message catalog.
> >>>
> >>>     This is nice from the point of view that it would solve the 
> >>>     language packs issue very cleanly and that (at least in GNOME) the 
> >>>     translations are already in the message catalog.
> >>>
> >>>     First problem is the performace hit with having to read every app's
> >>>     message catalog. We're already seeing problems because of the 
> >>>     amount of disk seeking involved with loading every .desktop file. 
> >>>     Add message catalogs into the equation and you now have to locate 
> >>>     each message catalog (by stat()ing for each locale alias) and 
> >>>     load it.
> >>
> >>Yes, this is right. But .mo is a binary and .destop is a text file. So for the milestone, If we change almost .desktop files to .mo files, I think the
> >>performance will be faster rather than the current implementations. One solution is to use one .mo file for the .desktop file.
> > 
> > 
> > I think you are misunderstanding what the performance problem is. The
> > problem is the need to open multiple files (both desktop and mo), and
> > for .mo file its even worse, as it requires multiple stats to locate the
> > right translation. Each stat of a file means a seek, and two seeks for
> > an open. Each seek is on average half a rotational delay on the HD,
> > which is a very long time in cpu clock cycles. Actually reading the file
> > once we've seeked to it is not a problem, relatively.
> > 
> > In fact, the stating and opening of many files in for instance the icon
> > theme spec has caused massive performance issues for implementations,
> > and we do *not* want that to happen again.
> 
> OK, you mean even if we use one .mo file only, the multiple stats effect the performance?

If you use only one .mo file for all desktop files that should be fine.
If you need to open another file for each desktop file you open then
that is a problem.

Each open of an mo file looks something like this:
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/gedit.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

Now, if this is done once at startup that is ok. But if its done once
per desktop file for possibly thousands of files then its not.

> My understanding is to read one by one .icon file.

> If possible, could you provide the measurable way?
> I have a sample implementation and I don't find the big delay on Ultra 10. so If I could show the exact time, it would be a really help for one
> reference. I think the concern needs to be investigated.

Things like disk and seek speed are difficult things to measure. You
need to make sure nothing is in the cache when you measure. This
basically means you have to cold-boot before measuring.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a suicidal white trash master criminal on the hunt for the last specimen 
of a great and near-mythical creature. She's a scantily clad punk college 
professor who don't take no shit from nobody. They fight crime!