9. jul. 2010 11.23 skrev zaheer ahmad <[email protected]>:
> 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)
You should enable snapshots.
>
> 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.
Snapshots will improve the memory use, the compilation time and the JS
execution time.
>
> 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
>
--
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
