hi Eric,
Thank you for the reply.
I can share the tests, but even a simplest html (below) shows the
difference. open the html say 10 times and here's some statistics of
V8 vs JSC (on Android/Eclair - snapshot disabled)
V8:
GC (Heap Capactiy/Available/NumObjects-NewSpace/SizeOfObjects)
889952:578256:1754:412048 (1st load)
1650368:747000:4060:1105292 (5th load)
3651616:1141716:15771:3033668 (10th load)
Triggers around 10 GCs
Load Time: 759ms
JS Time (all-GC/DOM/JS/compile): 520ms
JS Execution Time (VMState-JS): 264ms (out of this Instantiate and
ConfigureTemplateInstance (Function Template instantiation) takes
185ms)
Compilation (VMState-Compile): 200ms
JSC:
Heap size (65k)
No GCs triggered
Load Time: 387ms
JS Time (all-GC/DOM/JS/Parse): 40ms
I think snapshot should improve the builtin compilation time and not
impact the JS execution time. Overall, looks like there are more
objects in heap and template instantiation is costly.
Thanks,
Zaheer
--
<html>
<script>
function onLoad(){
document.body.innerHTML = "<p> hello </p>";
}
</script>
<body onLoad="onLoad()">
</body>
</html>
On Fri, Jul 9, 2010 at 2:15 AM, Erik Corry <[email protected]> wrote:
>
>
> Den 5. jul. 2010 11.53 skrev zaheer ahmad <[email protected]>:
>>
>> hi Eric,
>> Thanks for the reply. clear cache was triggered by the test case on
>> every page load and we expected it to be light weight as there is
>> hardly any js, but it turned out to be costly.
>>
>> furthur looking in to it suggests that v8 maintains all the bultin and
>> dom objects in the heap, where are jsc maintains it outside the heap,
>> so even without a clear cache, the heap grows quickly (~300-400k on
>> each page) on continuous page loads triggering many costly gcs in v8.
>
> I'm not aware of a big difference in performance here. Is the page cycler
> something you can share?
> I hope you are building V8 with snapshot support (this is standard in the
> Android build, so you probably are).
>
>>
>> thanks,
>> Zaheer
>>
>>
>>
>> On Fri, Jul 2, 2010 at 1:19 PM, Erik Corry <[email protected]> wrote:
>> > Calling a GC on clear cache is a heuristic, to try to find a good time
>> > to do
>> > a large GC. The thinking behind it was that clear cache would be called
>> > when memory was almost exhausted, and that it would be a good idea for
>> > V8 to
>> > reduce its memory usage at that point. It was expected that the clear
>> > cache
>> > event would be very rare.
>> > Is 'clear cache' happening a lot?
>> > In general a GCed system will often slow down dramatically just before
>> > running out of memory. Also, running out of memory is not a recoverable
>> > event. So it's best if you can avoid running out of memory. :-)
>> > Den 18. jun. 2010 11.25 skrev zaheer ahmad <[email protected]>:
>> >>
>> >> hi,
>> >> iam running some page cycler tests on android (with v8 - June 4
>> >> Bleeding Edge) that invoke LowMemoryCondition on every cycle (through
>> >> ClearCache). I have very limited js in my tests <0.5% evaluation time,
>> >> even then every request seems to be taking ~200-300ms. Is this a known
>> >> issue? if not i can hopefully simulate a test case.
>> >>
>> >> In addition, the trigger ClearCache which is primarily a disk clear
>> >> request may not be triggering a Low memory request IMO.
>> >> Interestingly the JSC version in this case is quite fast (though it
>> >> also seems be doing a compact). i havent checked the internals though.
>> >>
>> >> #if USE(JSC)
>> >> // force JavaScript to GC when clear cache
>> >> WebCore::gcController().garbageCollectSoon();
>> >> #elif USE(V8)
>> >> WebCore::Frame* pFrame = GET_NATIVE_FRAME(env, obj);
>> >> pFrame->script()->lowMemoryNotification();
>> >> #endif // USE(JSC)
>> >>
>> >> Thanks in advance for any inputs.
>> >>
>> >> Regards,
>> >> Zaheer
>> >>
>> >> --
>> >> v8-users mailing list
>> >> [email protected]
>> >> http://groups.google.com/group/v8-users
>> >
>> >
>> >
>> > --
>> > Erik Corry, Software Engineer
>> > Google Denmark ApS. CVR nr. 28 86 69 84
>> > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
>> > Copenhagen K,
>> > Denmark.
>> >
>> > --
>> > v8-users mailing list
>> > [email protected]
>> > http://groups.google.com/group/v8-users
>>
>> --
>> v8-users mailing list
>> [email protected]
>> http://groups.google.com/group/v8-users
>
>
>
> --
> Erik Corry, Software Engineer
> Google Denmark ApS. CVR nr. 28 86 69 84
> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K,
> Denmark.
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
