Bug 94548 - XGetWindowAttributes is 700 times slower on El Capitan than on older versions of OS X
Summary: XGetWindowAttributes is 700 times slower on El Capitan than on older versions...
Status: RESOLVED NOTOURBUG
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 2.7.8 (xserver-1.16.4)
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium critical
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-15 00:13 UTC by Dušan Peterc
Modified: 2016-03-15 22:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
demo which demonstrates slowness of XGetWindowAttributes on El Capitan (1.54 KB, text/plain)
2016-03-15 00:13 UTC, Dušan Peterc
Details

Description Dušan Peterc 2016-03-15 00:13:34 UTC
Created attachment 122303 [details]
demo which demonstrates slowness of XGetWindowAttributes on El Capitan

Lots of X Window programs use XGetWindowAttributes to check window visibility before drawing. I use it in my code, but toolkits like Motif also use it internally.
XGetWindowAttributes is VERY SLOW on El Capitan, approximately 700 times slower than on older versions of Mac OS X, or on Linux of comparable processing power.
As a result, programs work, but they are slow to the point of being useless - by clicking on menus, you can observe the menu being open and drawn, line by line. Or if a complex window is resized, it refreshes itself for minutes, before GUI becomes responsive again.
I have prepared a small Xlib only test program, one page, no toolkit, which calls XGetWindowAttributes in a loop while drawing colored rectangles.
Strictly speaking, XGetWindowAttributes is not necessary in the demo; it is there only to demonstrate how visibly slow it is, compared to older OS X versions or other X Window implementations.

Linux 4K, Suse 42.1; i7: 0.5 seconds
iMac 27, OS X 10.0.6; i5: 1.5 seconds
iMac 27 retina, OS X 10.11, i5: 10 minutes 58 seconds
Comment 1 Jeremy Huddleston Sequoia 2016-03-15 02:20:45 UTC
There’s not much we can do about OS regressions.
Comment 2 Jeremy Huddleston Sequoia 2016-03-15 21:26:04 UTC
BTW, for future reference, you can file bug reports against the OS at http://bugreport.apple.com

The performance regressions with 10.10 and later are already tracked at <rdar://problem/19116159>.
Comment 3 Dušan Peterc 2016-03-15 22:43:52 UTC
Should the bug be at least investigated or reported upstream?
How does one do that with Apple?
It is a pity that so much work, which went in making XQuartz, and ours to port the software to Apple, would go to waste if such regressions are not resolved.

I have looked at the XGetWindowAttributes source and can't see what could cause such slow response time.
http://www.opensource.apple.com/source/X11libs/X11libs-40.2/libX11/libX11-1.2.1/src/GetWAttrs.c
code is mostly filling in the structures.

The only possibly timing critical functions involve AsyncHandler but I don't know enough about X internals to be sure.

if (!_XReply (dpy, (xReply *)&rep, 0, xTrue)) {
 DeqAsyncHandler(dpy, &async);
 return (0);
 }
 DeqAsyncHandler(dpy, &async);

Is there a way to profile Xlib to verify where exactly is the time lost?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.