Siarhei Siamashka <[email protected]> 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. It might even be interesting to have it compiled in by default, but disabled unless it is turned on through an environment variable. Soren _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
