[webkit-dev] Re: [webkit-changes] [24907] trunk

[Andre-John Mas]

I am just wondering whether it should be the other way round, in that  
how many iterations can be done in time x. The logic here is that as  
processors gets faster a given number of iterations will eventually  
reach a value near zero. On the other hand for a given time period  
there is much more room for expansion on the number of iterations  
possible.

Andre

On 7-Aug-07, at 19:04 , Mitz Pettel wrote:

> If I understood the bug fix and the test correctly, then a test  
> like this might work: do 5000 iterations (instead of 30000) and  
> look at the ratio between the time the first 500 and last 500  
> iterations take.
>
> On Aug 7, 2007, at 5:22 PM, Antti Koivisto wrote:
>
>> On 8/7/07, Mitz Pettel <opendarwin.org at mitzpettel.com> wrote:
>>> On Aug 7, 2007, at 2:15 PM, antti at 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.
>>
>> 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.
>>
>>
>>   antti
>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev