[Pixman] Compute flags at validation time instea
siarhei.siamashka at gmail.com
Mon Mar 1 07:03:15 PST 2010
On Monday 01 March 2010, Benjamin Otte wrote:
> On Mon, 2010-03-01 at 15:44 +0200, Siarhei Siamashka wrote:
> > Also "Restructure the code to use switches instead of ifs" part probably
> > may have uncertain effect on performance. Optimization manuals say that
> > ifs are generally faster than switches when one of the cases has much
> > higher probability than the others.
> As that code is not performance-relevant - it's run only once pafter
> setting properties on an image - clarity is way more important than
> speed for this particular case.
A lot of code is not performance-relevant in general when looking at just some
isolated parts of it and there are only some obvious hotspots. But looking at
the bigger picture, all the performance-nonrelevant parts of code together
represent a large share of cpu usage in a program/library.
Being accurate and using "good" code constructs everywhere (and making it into
a habbit so that you do it automatically and don't waste excessive time) makes
the code perform better on average as a cumulative effect.
> Also, doesn't gcc tend to compile switch statements into ifs in a lot of
> cases anyway?
In this case we are at the mercy of the compiler. It can either:
1. use a jump table
2. do branching, based on value bisecting
3. do branching, checking the cases in the order they are listed
4. do something else?
Using all the same simple 'if' expressions explicitly in the preferred order
makes it harder for the compiler to screw up the performance, additionally
the 'likely'/'unlikely' macros can be used as probability hints.
I'm not saying that switch will be necessarily slower here. It's just that
having a good benchmark suite sensitive enough for detecting even minor
changes in the performance would help a lot when making such (nonsignificant)
More information about the Pixman