_XReply: performance regression in latest version
Submitted by Rami Ylimaki
Assigned to Jamey Sharp @jamey
Description
Compile the attached test program and run it with latest libX11 from FDO git. Use "ltrace -S ./test-xreply" to monitor system calls.
The test program executes a single XInternAtoms request with 100 atoms. As a result, _XReply is calling non-blocking read 200 times. It seems that whenever _XReply reads n replies, it will execute n*2 non-blocking reads that all fail with EAGAIN.
I tested the execution time of XInternAtoms with 100 atoms on a Debian Sid snapshot from today. The libX11 from Sid doesn't suffer from this problem and there is only one failing non-blocking read in _XReply. Then I compiled latest upstream libX11 inside Sid and installed it. Updating libX11 made the problem visible. On my machine, the XInternAtoms call with 100 atoms takes about 8 times longer (1ms vs. 8ms) if latest libX11 is used from FDO. I used ltrace for getting the execution times.
I'm not too concerned about the performance of XInternAtoms itself, but it is the easiest way to make this problem visible. The number of failing non-blocking reads has increased for other requests as well, but there are usually much less replies when handling other requests.
Version: git