Re: Static compose table in gtkimcontextsimple.c



On Thu, 2007-12-06 at 12:28 +0000, Paul LeoNerd Evans wrote:
> On Tue, 04 Dec 2007 05:38:56 +0000
> Simos Xenitellis <simos lists googlemail com> wrote:
> 
> > If you would like to help with bug 321896 it would be great. The current 
> > state is on how to make the table much smaller, even with the addition of
> > more keysyms. There is a script that converts en_US.UTF-8/Compose into a
> > series of arrays that should be easy for GTK+ to work on. 
> 
> OK, I've had a good read through that bug, and now I'm confused again.
> 
> Can someone explain why GTK has to have this large table compiled into
> it..? I thought X itself provided ways to perform input composition into
> Unicode strings. Otherwise, why do I have a file
> 
>   /usr/share/X11/locale/en_US.UTF-8/Compose
> 
> Can we just use that?

Note also that loading /usr/share/X11/locale/en_US.UTF-8/Compose causes
a large amount of per-process memory to be allocated, and quite a bit of
time spent parsing it. While the GTK+ table is "large", it is mapped
read-only so shared between all GTK+ applications. (*) (**)

I don't have any exact or recent numbers here; the Compose table was a
significant fraction of the per-process overhead when I measured it
before writing gtkimcontextsimple.c, and current UTF-8 table is much
bigger than anything I measured. On the other hand, it's possible that
optimization has been done within Xlib in the subsequent 5-6 years.

The original motivations in order of priority:

 1. Reliable compose sequences in non-UTF-8 locales
 2. Efficiency
 3. Cross-platform portability
 
1. is luckily no longer an issue, but the two still apply.

- Owen

(*) The Xlib problem could obviously be fixed by precompiling and
  mem-mapping the Compose tables, as we do for similiar things

(**) The one thing to be careful about when modifying
gtkimcontextsimple.c is not to save "size" by introducing relocations.
Arrays that include pointers to other arrays cannot be mapped read-only.
Other than that, go for it!

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]