DHTML perf bugs triaging -- plans

[Fabian Guisset]

Hi everyone,

as you may have noticed, a lot of bugs about DHTML performance issues
have been entered in Bugzilla in the last couple of months.
So many in fact, that the amount is quickly becoming unmanageable for
the DOM developers and QA's.
Furthermore, 99% of those bugs are due to the same problems, which range
from too much painting, to too much style resolution, via DOM and layout
problems. The key is that none of the new bugs bring any new
information, apart from Yet Another URL (TM).

So, together with Prashant Desale, Sivakiran Tummala (DOM QA's) and
Johnny Stenback, we have decided to simply "blindly" dupe all of the
DHTML perf bugs to the tracking bug (bug 21762), apart from those that
really have important information.
In order not to miss any important bug, the plan is that, when we have
brought the DHTML performance to an acceptable level, we will go through
all the dupes of the tracking bug and verify that they are behaving
correctly. If one is still slow, we will reopen and fix it.

I will open another tracking bug for internal use only where we will put
the most interesting minimized testcases. Individual bugs will be filed
for precise issues. Please do *not* add comments or change dependencies
on the bug I will file. All comments should be posted in this thread.
Thanks in advance.

We believe this is the only way we will stop the DHTML perf bugs from
sucking all our bugmail quota and bloating our bug lists to death.

How do we plan to bring the DHTML performance to an acceptable level,
you ask? Profiling, profiling, and more profiling.
Then fixing bugs. We really hope that the performance will be acceptable
for Mozilla 1.0, but unfortunately we cannot guarantee anything.

By all means, we encourage you to write _minimized_ testcases that
demonstrate a _single_ problem. For example, "moving a large clipped div
with overflow:scroll is slow, but gets fast without overflow:scroll"
would be worthy of its own bug. But 'this DHTML animation is slow and
pegs my cpu" is not.

-Fabian-who-keeps-you-updated-of-what's-going-on.

[Markus Hübner]

Think we know where our problems are and starting with a few suggestions

http://bugzilla.mozilla.org/show_bug.cgi?id=124178#c11
http://bugzilla.mozilla.org/show_bug.cgi?id=75121

It would be cool if top-sites like www.sony.com perform fine on
Mozilla1.0 - there is still some time :)
Basic and I are currently trying to create testcases and DHTML test
suites to support profiling and further analyse the main issues.

:: matic

[Markus Hübner]

Think we know where our problems are and starting with a few suggestions

[Markus Hübner]

Think we know where our problems are and starting with a few suggestions

[Robert O'Callahan]

Remember to CC me on any bugs that might have something to do with the
view manager :-).

Rob

[Robert O'Callahan]

Fabian Guisset wrote:
>
> How do we plan to bring the DHTML performance to an acceptable level,
> you ask? Profiling, profiling, and more profiling.
> Then fixing bugs. We really hope that the performance will be acceptable
> for Mozilla 1.0, but unfortunately we cannot guarantee anything.

BTW, it sure would be helpful if one or more Tinderbox machines were
running some basic
DHTML performance tests. If you had a suitable bunch of tests then
consider submitting them to st...@mozilla.org.

Rob

[tradervik]

Fabian Guisset wrote:
> Hi everyone,
>

> [plan snipped]
>
> -Fabian-who-keeps-you-updated-of-what's-going-on.
>

Excellent plan, and kudos for posting the update. Now I know
why I have 15 emails in my inbox. ;-)

[Chris Casciano]

in article 3C6C6AB4...@cs.cmu.edu, Robert O'Callahan at
roc+...@cs.cmu.edu wrote on 2/14/02 8:56 PM:

What are you looking for in potential tests? Any docs anywhere?

--
Chris Casciano home >> http://www.placenamehere.com/
words > http://www.chunkysoup.net/
10s...@placenamehere.com fun >>> http://www.neuralust.com/~cac6982/