-Lost wrote:
I have been watching code execution in various situations
and I have noticed something.
On the first test my example gave me obvious results.
One method was far faster than the other. However, upon
executing the code again (without refreshing the browser)
the two tests were almost identical in speed.
I am not sure if this has something to do specifically
with JavaScript (and/or its engine) or if this is just
something browsers try to implement.
What type of "code execution caching" am I seeing?
Popular browsers have decent javascript engines that work pretty well
in most situations, but this kind of observations may occur. IMHO the
first thing to do is to make sure that the javascript code itself does
not have any (hidden) memory leaks. This isn't as obvious as it may
sound; especially in complex architectures.
This is actually the most you can do. Once the code is passed to the
engine for execution, all you can do is pray that it's a decent
engine. You can't control the mechanisms that are used there.
Regarding your test case, it looks like the memory isn't flushed. The
browser's javascript engine must have a (un)justified reason why it
keeps it in memory. AFAIK there is only one (JScript) command to clear
up such "garbage", but you will not want to use it:
CollectGarbage()
See:
http://groups.google.com/group/comp....3c7c11f20ad185
I've done javascript memory benchmarks some time ago comparing
Microsoft Internet Explorer and Firefox memory performance. These
indicated that Firefox generally has a much stronger allocation
model.
--
Bart
