[PATCH] Cache xkbcomp output
Adam Jackson
ajax at nwnk.net
Thu Jul 19 13:33:48 PDT 2012
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
More information about the xorg-devel
mailing list