On 8/26/07, zwetan <[EMAIL PROTECTED]> wrote: > humm... I don't see what haxe with an .abc target would bring ? > haxe, avmplus, flash player,... they all need an initialization time
They do, but with the Flashplayer, you have the GUI. > the overhead you're talking about is already substracted, > basically getTimer() just give you the time elapsed since the flash > player started, Yeah, I know. With 'time', you'd have to do a test run without execution, or maybe better a single repetition, and subtract that from the result. But that result would be only what is actually spent on execution, with getTimer you measure elapsed time from beginning to end, everything else that happens on your system meanwhile adds o the result. That's why I suggested counting only the fastest result, because it's the one the least tainted by other processes. > using 'time' would not really be more accurate, just more precise, > and could give you the result of more tiny difference within 4ms > (which the getTimer can not really do). 'time' gives you the CPU time of the process. That's more accurate than elapsed time. > but my point here is if you run a test that last 100ms, be it 96ms or 104ms > is not really the problem, as all your other test have the same > limit/difference in precision. Agreed, it doesn't make that much difference. > > If you use getTimer to measure the duration, the fastest test run is > > the one to look at. Slower results only mean that the system spent > > time on other stuff while running the test, or the GC had kicked in. > > > > hum ... I don't agree here > on the 3 stats I gave, the only param changed is the number of iterations > 100.000 / 1.000.000 / 10.000.000 > so sure the more iterations the more time a function execution gonna take > but the results stay consistent Yes, but that's not what I meant -- the way I test is that I make a number of runs of a given number of iterations, so if I have 5 measurements of a test with n iterations, I take the one that took the least time. > whatever the system spend time on other stuff, GC kicked, etc., > the optimized2 test is always executed faster than the standard test, > the duration numbers sure can be different (system busy, other system, > RAM, etc.). > > but implementing a system time function for avmplus being not that difficult, > I'll look into that, see if it bring more infos That would be nice, but Adobe will document the built-in profiler soon (whenever that will be), and it probably does exactly that among other things. So, don't put too much work into it. > but mind also that avmplus !== the flash player Yeah, especially in Ecma mode. Mark _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
