On Tuesday 28 September 2010 07:01:55 Soeren Sandmann wrote: > Siarhei Siamashka <siarhei.siamas...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman