On Sun, 2005-06-12 at 22:53 -0400, Morten Welinder wrote:
>
> > For non-local servers without Render, Cairo will allow us to eliminate
> > the round-trips... a huge win.
>
> "Show me the money!"
>
> Back in the real world, new code goes in and someone files a performance
> bug. Then you, Owen, seem to take that as a personal insult and close
> it as NOTABUG or WONTFIX.
>
> Exhibit 1: bug 94718. A clear, to-the-point bug report that something
> (namely greying of toolbars) had gotten so much slower that it was a
> problem. It still is.
The bug was originally filed in useless form, I indicated as much.
when it was reopened with more useful data, it was left open.
The data in the bug report is still really not very good ... all
the profiling data was done in the remote case, and may well be
completely irrelevant if the actual time is spent in roundtrips
to the server (I think it is).
But with the test case, there's the possibility that someone could
pick up the bug, get some better data and come up with a patch.
> Exhibit 2: bug 123538. Pango/GtkTreeview gets very slow with lots of
> data, a situation that "less" handled well a decade or two ago. I
> routinely use "less" on files larger than 1GB or with lines that are
> thousands of characters wide. While you didn't actually close this bug
> (we kept it under "Gnumeric") you seem to think I am outside what you
> designed for, hence my "Hello World" poke.
You clear have *no* idea what I'm saying in comment #7. Or you'd
realize that looking at the performance of 'less' is completely
irrelevant here. Fixed with character grids without complex text
handling are inherently fast. That doesn't mean that it's easy to
make GtkTextView just as fast on the same font and data.
> Exhibit 3: bug 104683. General Pango performance with a patch that
> at the time cut 70% of cpu usage for the all-ASCII case (such as
> numbers) that Gnumeric uses heavily. You NOTABUG'd it *twice* (and
> "futured" it once) as evidently Pango's performance cannot possibly
> be problematic.
Problems with this "patch":
- The 70% timing was done with code paths that weren't used by
almost anybody when you filed the bug report, and aren't even
minimally supported today
- The patch made assumptions [width(AB) = width(A) + width(B)]
that were planned to be broken at the point you filed the
bug report and have since been broken.
- The patch was lots of completely unrelated things shuffled
together, many without any real justification
In terms of NOTABUG, that's clearly explained in the comments
in bug report. When you analyze the bug report, it comes down
"Pango is slower than Morten likes". It's slower than Owen likes as
well. Having a bug open like that does nothing to make Pango better.
I want bug reports to be specific to particular issues.
I left it open eventually because I got tired of fighting the
battle.
> I am somehow reminded of the word "attitude" reading these old, but
> still-open, bug reports.
What I try to make very clear on performance bug reports is that:
A) Reports of something being *slower* than some previous version
of GTK+ is not, in itself an issue. Things get slower typically
because we add interesting and important features.
Something being slower is *only* a problem when it is a performance
bottleneck.
B) Bug reports should be about specific fixable items. A bug report
complaining that Pango is slow is not specific enough to be
useful.
C) Random patches that "optimize" some function that doesn't show
up on profiles and without any benchmark to show that that patch
makes a difference will not be accepted.
It is in fact pretty hard to get me to take a performance patch for
Pango. This is not because I don't want to improve Pango performance,
it's because I've spent weeks and months working on Pango performance,
so if a patch was easy to come up with, it's most likely either
close to irrelevant or incorrect.
There certainly are some areas where things could be improved (and
some patches in Bugzilla to do so, especially for Arabic/Indic shaping),
but we're talking mostly a few percent speedups.
With a well-written ASCII-only codepath and programmatic options to
degrade layout quality for speed, you might manage to get a 50% speedup
for text *layout*. But Gnumeric cares most about text
*rendering* speed, and with the X servers most people are running
currently, speeding up text *layout* 50% will speed up rendering
maybe 10%.
> > Rendering speed is 90% an X server issue.
>
> I would normally define rendering speed as a measure of how fast you get
> your pixels on the screen. With that definition in mind, look at bugs
> 94718 and 104683 above and see that getting pixels on the screen got
> much slower with constant X server. The toolkit is much, much more
> than 10%.
Rendering *DIFFERENT THINGS*. Yes, rendering alpha-composited images
on a remote sever without the RENDER extension is slow. Duh. Cairo,
as I noted above, would allow someone with a real interest in *fixing*
this issue rather than just complaining to make progress.
Regards,
Owen
Attachment:
signature.asc
Description: This is a digitally signed message part