Bug 21377 - GC goes off the deep end with large array
Summary: GC goes off the deep end with large array
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Maciej Stachowiak
URL: http://nerget.com/mandelbrot.html
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-04 17:52 PDT by Oliver Hunt
Modified: 2012-09-11 19:05 PDT (History)
2 users (show)

See Also:

Attachments
Profile (1.35 MB, application/octet-stream)
2008-10-04 17:56 PDT, Oliver Hunt 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Hunt 2008-10-04 17:52:03 PDT 
If you compare the time taken first the first phase (calculation) of the linked mandelbrot demo to any other browser you'll see we get thoroughly beaten.  Shark shows this to be Basically entirely GC bound with 86.4% of time spent in JSArray::mark

To reproduce:
1. Check the Slow case check box
2. click the start link

I'm not sure if this is a bug due to marking an array being slow, or something forcing us to collect way more often than we should be (extra cost of array storage etc)
Comment 1 Oliver Hunt 2008-10-04 17:56:28 PDT 
Created attachment 24097 [details]
Profile

This is a prfile of the copmutation portion of the slow path (eg. excluding the drawing).
Comment 2 Gavin Barraclough 2012-09-11 19:05:08 PDT 
We don't go off the deep end on this any more.  We're faster than Firefox & Opera on both tests.  We beat Chrome with "use slow path" set, they win without.  The described bug (86.4% time in JSArray::mark) no longer exists.  I'm saying this bug is fixed - I don't think we're currently going to closely track progress on this specific test.