[PATCH] Cache xkbcomp output
daniel at fooishbar.org
Thu Jul 12 16:35:35 PDT 2012
On 12 July 2012 23:27, Keith Packard <keithp at keithp.com> wrote:
> Daniel Stone <daniel at fooishbar.org> writes:
>> You need to do at least some rudimentary stat() work so that you'll
>> rebuild the keymap if the files it uses changes.
> My plan is to simply put that work on the package installer loading new
> files into the xkb directories. A simple post-install hook that removed
> all of the files in the server's cache directory should make that work
Ugh, please don't do that. I already get people (validly) complaining
that XKB is unintuitive enough ...
> I could make the in-server caching optional if you like, either command
> line flag or configure option. Attempting to figure out which files are
> relevant to stat seems like a huge effort.
You could just do everything under the data root directory, although I
guess spinning disks might not love that?
>> Aside from that, it's our best hope short of forking xkbcommon, adding
>> back some of the bits we removed as pointless, and smashing that into
>> the server (volunteers?), so, why not.
> Even then, this avoids the cost of compilation, which isn't
> insignificant. So, I think we want this regardless. Directly compiling
> the file in the X server would avoid a whole pile of security drama,
> otherwise it doesn't seem like a huge win (at least according to the
> profiles I've seen).
Eh? Admittedly this is with xkbcommon rather than xkbcomp, but if I
compile keymaps (basic evdev/US) and then unref (i.e. free) them in a
tight cycle, it takes me a steady 8.5ms per compilation. Admittedly
this is with an SSD, but still, I'm having trouble figuring out where
the 'compilation is super heavyweight and we can't do it ever' meme
Even xkbcomp doesn't seem to be woefully slow, at least since 1.2.0's
performance optimisations, plus having a libX11 which has all the
keysyms in its table, rather than needing to go to XKeysymDB all the
That being said, I'm not opposed to doing caching given that I don't
really have any plans to merge xkbcomp in myself right now, but the
package-manager thing (while attractive) is just a total copout, and
will only lead to yet more confusion.
More information about the xorg-devel