On 8/26/07, Mark Winterhalder <[EMAIL PROTECTED]> wrote: > > They do, but with the Flashplayer, you have the GUI.
yes that's the point :) if you re interested in testing the pure execution within the VM (Tamarin); removing the GUI yes is the thing to do, but in a case like PV3D which using that GUI to display 3D you need your tests to run with the GUI so you know if the optimization you're making better things or not. > 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. > yes this approach is the more precise and accurate, but this is only usefull if you want the exact time of execution, which can be usefull if you want to compare the execution of code between say Avmplus and a Java VM but this thread it's about finding AS3 construct that are faster compared to other slower that both run in the same VM but just be sure they are really faster. This could totally change with another flash player, a newer version of the language (AS4), etc. If you want to optimize something runing in FP9, the same trick that works in other VM (like Jave or any other) does not necessary works for that particular VM, you need statistics to be sure. > > 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. I was saying accurate for "being sure that a particular trick is consistent", reading the wiki you can think that (value*.5) is faster than (value/2) (the flaw of the micro-benchmarks) but I think the code I showed earlier prove it's not. [...] > > 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. > there's not really a lot of work to put in :) but you're right it's better to wait for the Adobe profiler which would surely be more efficient/tested/etc. than a simple function call to the system done in 10mn. zwetan _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
