Another option for this test is to make it a PLT, like the nesting PLT
that Hyatt recently checked in.
Geoff
On Aug 7, 2007, at 7:44 AM, Mitz Pettel wrote:
On Aug 7, 2007, at 5:22 PM, Antti Koivisto wrote:
On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote:
On Aug 7, 2007, at 2:15 PM, [EMAIL PROTECTED] wrote:
- added performance test. With debug build on MBP this takes about
1.5s to
run.
* fast/block/basic/stress-shallow-nested-expected.txt: Added.
* fast/block/basic/stress-shallow-nested.html: Added.
(emphases mine). Nothing about that makes sense to me.
Are you objecting to testing performance regressions as part of the
test suite in general or particular method here? I'm open to
suggestions.
Hi Antti,
I do not understand the purpose of the test and how it is supposed
to serve that purpose (two of the reasons that I am baffled are that
it is my understanding that there are facilities to track
performance within fractions of a percent, and that I am not aware
of other tests that have use elapsed time internally as their
success criterion).
It does not take long to run (300ms on release, 1.5s on debug MBP) so
I thought it would be appropriate for automatic test. There are
similar cases in the suite already. It needs to have non-zero
execution time so that O(n^2) nature of the bug shows up in testable
way.
On the computer I run the tests on, that single test alone takes
roughly as much time as all the other 229 tests in fast/block
together.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
