[cairo] Pixman - refactoring of fbFetchTransformed - performance issue

[Soeren Sandmann]

Vladimir Vukicevic <vladimir at pobox.com> writes:

> On Feb 18, 2008, at 2:05 PM, Soeren Sandmann wrote:
> 
> > Bertram Felgenhauer <bertram.felgenhauer at googlemail.com> writes:
> >
> >> That's about 30%. Now the question is, is this acceptable for a
> >> refactoring that significantly improves maintainability or not?
> >>
> >> I'm leaning towards keeping the change.
> >
> > Agreed, the refactoring is a substiantial readability improvement. We
> > should keep the change even with this performance impact.
> 
> Er, a 30% performance loss for a common case of minifying/magnifying  
> an image really doesn't seem acceptable to me.. if it was 3-5%, then  
> sure, but 30% is really very high.  

The question is whether trying to make the existing transformed path
really fast is worthwhile. It involves an indirect call per pixel, and
I don't see any way of getting rid of that without lots of code
duplication. This is just never going to be very fast.

The refactoring added another indirect call per pixel on top of this,
which I suspect is the main reason for the 30% slowdown, though I
haven't profiled.

If someone shows up with a patch to get rid of the additional indirect
calls while keeping the refactoring, I wouldn't be opposed, but
instead of attacking those 30%, I think it's a better plan to just
write fast paths for the cases that actually show up in practice.


Soren