Scratch GC performance (was Re: [PATCH] dix: Reshuffle ScreenRec to pack holes)

[Adam Jackson]

On Thu, 2010-05-20 at 11:27 -0700, Jamey Sharp wrote:
> On Thu, May 20, 2010 at 11:17 AM, Adam Jackson <ajax at nwnk.net> wrote:
> > The numbers, sadly, are pretty clear:
> >
> > 717000.0   518000.0 (  0.72)   Map window via parent (4 kids)
> >
> > That's not really a performance hit I'm willing to take.
> 
> A 7%-28% hit? Yeah, not so much. Thanks for checking!
> 
> Do you have a shortcut to working out which x11perf tests are going to
> hit a particular code path? I'd have been happy to test this myself if
> I'd had any idea which tests would be reasonable.

I pretty much just worked backwards by grepping for callers of
GetScratchGC.  I first looked at the general miPolyArc case and tried to
conjure up a test that would hit it.  x11perf -rop GXxor -wdcircle100
will do it, but the performance is (predictably) so abysmal that you
can't measure a difference; anything you can only do 2e3 of per second
isn't going to be affected by the overhead of one malloc per.

Window ops, on the other hand, are in the 2e6 per second range.  So when
I saw a match in miexpose.c, I connected the dots: exposure processing
will naturally need a scratch GC, because the server has to use one to
do the exposure painting, so any tests that generate exposure paints
will work.

> Running all of x11perf is too painful for a quick "I wonder if...?"

Irritatingly, part of this is because x11perf tries very diligently to
estimate test execution speed _before_ getting the actual numbers.  So
if you say -time 1, it will calibrate every test for ~5 seconds each
before running it for 1 second per rep.  Apparently, back in the dark
ages, we didn't have timer signals to handle that kind of crap for us.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100521/57e82235/attachment.pgp>