[PATCH] Cache xkbcomp output

[Adam Jackson]

On 7/12/12 7:35 PM, Daniel Stone wrote:

> 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
> started.

I think there's a combination of factors that pile on to make it worse 
than you'd expect.

One, while it's compiling, xserver has to block signals, because we 
slurp the results back in with stdio and nobody's stdio is signal safe. 
  That means you block silken mouse.  Fixable enough, it merely requires 
the will to do so.

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.

Three, xserver's a huge process and xkbcomp is not, execing the latter 
means copying and then tearing down a ton of pagetable state.  This is 
the vfork() optimization case, would be lame to need to lean on vfork 
though.

- ajax