[Pixman] [RFC] Performance reporting capabilities for pixman?

[Siarhei Siamashka]

On Tuesday 28 September 2010 07:01:55 Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > Let's face it, I think the end users rarely report performance problems
> > in pixman unless the performance is really notoriously bad (and not
> > ignored because "it's software rendering, so it is expected to be
> > slow"). Finding real performance bottlenecks in pixman requires running
> > a profiler and being able to actually interpret its logs.
> 
> Yeah, in fact almost all users never report *anything* unless it's so
> broken that they can't possibly work around it. They have been trained
> to do this because many projects simply ignore bugs for years in some
> cases, and because bugzilla is a huge pain to deal with.
> 
> > I wonder if it would make sense to add an extra configure option for the
> > special profiling enabled pixman build which would do:
> > 1. Avoid caching fast path lookup failures
> > 2. Once hitting slow path, record the type of operation, image color
> > formats and image flags.
> > 3. For each unique slow path variant, accumulate the number of times it
> > got hit, the total number of (destination?) pixels which got processed,
> > the total number of scanlines.
> > 4. Once per N minutes, spam into syslog with the current accumulated
> > statistics.
> 
> This all makes sense to me.

Here is a work-in-progress branch with the initial variant slow path reporting 
code:
http://cgit.freedesktop.org/~siamashka/pixman/log/?h=perfstat-wip

After a few different experiments, I decided to just report 8 first slow paths
uses per process. And also report 8 worst slow paths on exit, which is actually
most interesting.

Probably it also makes sense to "grade" slow paths based on their complexity
and allow filtering based on this. For example, nontransformed fast paths 
are quite easy to implement (at least C fast paths). Nearest scaling is also 
not too difficult (assuming that we don't have a case when both source and mask
are scaled, use different scale factors and/or both don't COVER_CLIP at the
same time). Doing bilinear scaling and compositing in a single pass is more
difficult and may be even not worth implementing.

> It might even be interesting to have it compiled in by default, but disabled
> unless it is turned on through an environment variable.

Yes, this needs to be decided before the final patch is ready. Always enabling
the code for slow path reporting may indeed make sense. And the environment
variable may also be used to configure verbosity level.

For converting the into a human readable format, an additional ruby script is
used for now. Maybe it needs to be converted to perl a bit later. Or maybe this
flags decoding can be implemented in C and used directly from the library
itself.


Anyway, here is an example of usage of this code at the moment. It would be 
nice if somebody could also try it and provide some feedback. And there is also
a possibility that it may help to find some good candidate for optimizations
even now.

# tail -f /var/log/messages | ruby /home/ssvb/pixman/test/perfstat-decode.rb

[...]

Oct 20 01:28:41 i7 firefox: pixman slow path: op=3 s=00000001|002E2A7F 
m=08018000|002F0A7F d=08018000|002E0A7F - 20/1798 (4.133 MPix)

OVER
    solid                 a8                    a8                   
    -- src --             -- mask --            -- dest --           
    NARROW_FORMAT         NARROW_FORMAT         NARROW_FORMAT        
    NO_ACCESSORS          NO_ACCESSORS          NO_ACCESSORS         
    NO_ALPHA_MAP          NO_ALPHA_MAP          NO_ALPHA_MAP         
    UNIFIED_ALPHA         UNIFIED_ALPHA         UNIFIED_ALPHA        
    NO_NORMAL_REPEAT      NO_NORMAL_REPEAT      NO_NORMAL_REPEAT     
    NO_PAD_REPEAT         NO_PAD_REPEAT         NO_PAD_REPEAT        
    NO_REFLECT_REPEAT     NO_REFLECT_REPEAT     NO_REFLECT_REPEAT    
    NEAREST_FILTER        NEAREST_FILTER        NEAREST_FILTER       
    NO_CONVOLUTION_FILTER NO_CONVOLUTION_FILTER NO_CONVOLUTION_FILTER
    AFFINE_TRANSFORM      AFFINE_TRANSFORM      AFFINE_TRANSFORM     
    ID_TRANSFORM          ID_TRANSFORM          ID_TRANSFORM         
    X_UNIT_POSITIVE       X_UNIT_POSITIVE       X_UNIT_POSITIVE      
    Y_UNIT_ZERO           Y_UNIT_ZERO           Y_UNIT_ZERO          
    IS_OPAQUE             SAMPLES_COVER_CLIP                         
Oct 20 01:28:41 i7 firefox: pixman slow path: op=1 s=00000002|003EB676 
m=00000000|00000000 d=20028888|002E0A7F - 118/947 (0.076 MPix)

SRC
    pixbuf                null                  a8r8g8b8             
    -- src --             -- mask --            -- dest --           
    NARROW_FORMAT                               NARROW_FORMAT        
    NO_ACCESSORS                                NO_ACCESSORS         
    NO_ALPHA_MAP                                NO_ALPHA_MAP         
    UNIFIED_ALPHA                               UNIFIED_ALPHA        
    NO_NONE_REPEAT                              NO_NORMAL_REPEAT     
    NO_NORMAL_REPEAT                            NO_PAD_REPEAT        
    NO_REFLECT_REPEAT                           NO_REFLECT_REPEAT    
    BILINEAR_FILTER                             NEAREST_FILTER       
    NO_CONVOLUTION_FILTER                       NO_CONVOLUTION_FILTER
    AFFINE_TRANSFORM                            AFFINE_TRANSFORM     
    HAS_TRANSFORM                               ID_TRANSFORM         
    SCALE_TRANSFORM                             X_UNIT_POSITIVE      
    X_UNIT_POSITIVE                             Y_UNIT_ZERO          
    Y_UNIT_ZERO                                                      
    IS_OPAQUE

-- 
Best regards,
Siarhei Siamashka
-------------- 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.freedesktop.org/archives/pixman/attachments/20101020/7f4c7268/attachment.pgp>