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 <opendarwin.org@mitzpettel.com> wrote:
On Aug 7, 2007, at 2:15 PM, antti@webkit.org 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev