[PATCH] Cache xkbcomp output

[Daniel Stone]

Hi,

On 19 July 2012 21:33, Adam Jackson <ajax at nwnk.net> wrote:
> I think there's a combination of factors that pile on to make it worse than
> you'd expect.

Oh no, we're talking about totally different things here.  When I said
with xkbcommon rather than xkbcomp, I meant that this thing:
http://cgit.freedesktop.org/xorg/lib/libxkbcommon/tree/test/rulescomp.c#n70
takes 8.5-8.6 seconds to run on my laptop.

Forking xkbcomp, feeding it a description on stdin, having it compile
a keymap then serialise that to stdout, reading that back out in the
server and then re-parsing it, is a total total disaster, I know.
That's gotta be a lot more than 8ms.

> Two, 8ms is half a frame, so if you _do_ hit it you run good chances of
> missing a vblank, since you're starving out other clients.  Also fixable, or
> at least band-aid-able, if we're willing to rewrite the guilty XKB requests
> to block the client, fire off xkbcomp, and complete it asynchronously.

I don't think 8ms is that bad, to be honest.  In an ideal world, we'd
never fork xkbcomp, just do it all in-process with xkbcommon and cache
what we can (i.e. straight rules compilations, rather than 'the
current keymap plus misc').  If clients are compiling weird keymaps
all the time, then I'm honestly pretty glad we're showing that up so
we can go yell at people.  Same way I was kind of glad for the popen
vs. signals bug a while back, because it showed up the fact that
OpenOffice used to ask us to rebuild the keymap every time you opened
a pop-up menu.  Good incentive to fix catastrophically broken clients.

Cheers,
Daniel