What's wrong with xkbcomp?

[Simos Xenitellis]

On Wed, Sep 24, 2008 at 12:18 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Tue, Sep 23, 2008 at 09:35:12PM +0100, Simos Xenitellis wrote:
>> An issue that is often discussed is the xkbcomp utility, that parses
>> the xkeyboard-config configuration files
>> and produces a binary XKM file that X.Org can read and take the
>> keyboard layout settings from there.
>>
>> Apparently, xkbcomp has performance issues when running on small devices.
>> On modern computers, xkbcomp is very fast. In the process of
>> diagnosing where the problem is,
>> I would like to ask for a sample of command-line options
>> that are used when you try to run xkbcomp on a small device.
>>
>> So, what parameters do you give to xkbcomp when you invoke it on these
>> small devices?
>
> setxkbmap -print | xkbcomp -xkb - foo.txt 2>/dev/null still takes 0.1sec
> on my laptop, with a completely warm cache.  With a cold cache, it takes
> around 1.3sec.  Given that we currently run this twice on startup, that's
> 1.4sec just compiling keymaps.  Ugh.
>
> Plus, why do we fork an external program, feed it a text description of
> five strings which is then fully lexed, have that generate an
> XkbDescRec, serialise the XkbDescRec to a binary format (losing
> information in the process) somewhere in the filesystem, read that and
> then deserialise to ... an XkbDescRec?

I managed to replicate and I get similar times.

The next step in replacing xkbcomp would be to list any of the
structures we many want to eliminate or reduce some of the fields.

xkb_keymap
    |____ xkb_keycodes
    |____ xkb_types
    |____ xkb_compatibility
    |____ xkb_symbols
    |____ xkb_geometry

Then, write a library using either the existing grammar/code or
rewrite it, that parses the configuration files and fills in an
XkbDescRec structure. This can then be added to Xorg.

In this process of creating a library, what I see is that there will
always be time spent in parsing again and again. If we can cache some
part of the configuration that does not change often, we can save
time.

For example, in

 setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "xfree86+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+gb+gr:2+group(shifts_toggle)+compose(menu)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

only xkb_symbols{} is likely to change by the user, when X.org is used
on a small device. If it is possible to add an external keyboard to
the small device, then xkb_geometry, xkb_keycodes may change as well.

Additionally, when a user changes a setting in the keyboard layouts
dialog box and chooses to Apply/Save, the UI app could simply do the
necessary parsing while showing an hourglass, and produce an
optimized, maybe binary format, file, that can be de-serialised fast
by the X server. In this workflow, X.org would simply need to add
support to read the configuration from an optimised file format and
construct an XkbDescRec structure.

Any input on this?

Simos