[Xorg] [PATCH] Cached XIM data

Jim Gettys Jim.Gettys at hp.com
Mon Aug 9 12:30:32 PDT 2004


Thanks Lubos, for the data...  You are confirming what we were
already suspecting, from a different direction (just the size
information).

> 
>  The problem is basically that XIM parses the matching Compose file 
> from /usr/X11R6/lib/X11/locale (which happens to be the huge 
> en_US.UTF-8 one for UTF8 locales) and builds internal representation of this 
> data. The file is more or less constant, but XIM parses it once per 
> application startup.

Yeah, I can imagine parsing half megabyte files for every
application startup isn't a good idea...

en_US.UTF-8/Compose, and pt_BR.UTF-8/Compose are over a half megabyte
each.

> 
>  The imLcIm.c patch tries to solve this problem in similar way KDE's ksycoca 
> stores data. After XIM parses the Compose file, the code computes how much 
> memory the internal representation needs, allocates such block of memory, and 
> copies the internal representation there, including adjusting the pointers. 
> This avoids malloc() overhead, and allows read-only mmap()-ing of the block 
> (the internal representation doesn't appear to be ever modified after it's 
> created). Next time it's attempted to be mmap()-ed at the proper address, and 
> if that succeeds, bingo, QApplication time is again at 0.08s. Still without 
> the fonts of course, fontconfig needs something similar.
> 
>  The second patch caches a repeatedly requested information that is parsed 
> from another file.
> 
>  There are several things I'm unsure about the patch:
> 
> - It uses things like mmap() or posix_memalign() which could cause trouble to 
> all those crappy Nulix platforms out there. It should be just a matter of few 
> #ifdef's, but I don't know how you do checks for such features.

On platforms without mmap support (are there any around we still care
about?), you'd just open and read the data...

> 
> - I'm not sure where to store the cache file. KDE has special place for cache 
> files, but I don't know how to do that with non-KDE apps. The patch now 
> stores it in /tmp/xim, the /var/X11R6/cache/ or /var/cache are Linux-ism 
> AFAIK. Moreover this should be probably saved per-user for paranoia reasons, 
> or shouldn't it?
> 

Computing this once at build time seems more sensible to me.

But is there any reason why these files are so gigantic?  And whether
there are other solutions?  Is there someway we can leverage libc
functions that may not have existed when the Xlib implementation was
(mis)designed?

Does anyone really understand the input method stuff properly?

(we were just discussing this area today on the architecture call,
and what to do about it.  Thanks for the ammunition to go after it).
                              Regards,
                                    - Jim





More information about the xorg mailing list