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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
