Intermittent performance problem on large table

• Component: Layout and Rendering
• Status: RESOLVED WORKSFORME

[Samuel Allen]

I have, on my hard disk, a large HTML file that contains a single table and a JavaScript timer. When you 
load this file, the JavaScript calculates the amount of time used in rendering the page.

Safari 412.2 that shipped with Tiger is extremely well-behaved on this page and reports consistently 
low scores. Its scores, in seconds, are 1.48, 1.49, 1.45, 1.44, and 1.44.

Earlier WebKits, from around the time the project went public, also scored consistently low (although 
not as low as Tiger's Safari). I think these were in the 1.55 or so level.

The latest WebKit builds, both built on my machine and downloaded from the nightly repository, are 
very erratic with the timings on this page. Many times when this page is loaded, the time in seconds will 
be as high as 3 or 4. The time seems to end up, after several reloads, at around 1.55. (The timings I 
collected were 3.84, 3.20, 1.57, 1.55, 1.57.)

There definitely seems to be a regression here, although I am unsure where. I haven't profiled the page 
load yet. These are all deployment builds. I can reproduce this problem reliably on my Mac.

I will try to attach the HTML file....

[Samuel Allen]

Created attachment 3234 [details]
Test file

[Samuel Allen]

This might only show the problem when you load the file from the hard disk directly.

[Samuel Allen]

This occurs much less often in recent builds of WebKit, but after enough tries I can still reproduce the 4-
second load time.

[Samuel Allen]

A couple notes: First, the performance problem is much less likely to occur now, although it does 
occasionally occur. Usually, the first load is as fast as subsequent loads. Second, the version of Safari 
shipped with Tiger also has this bug, and it occurs about as often as it does in the ToT.

So, the "regression" part of this bug seems to be fixed, but I won't close the bug completely because the 
first load of this page still sometimes is very slow.

[Dave Hyatt]

Old Safaris with local files used to map them entirely into memory, lock up the UI, and then do one render.  This made the overall render time faster but the tradeoff was that nothing would show at all until the entire file was parsed.

Newer Safaris will do multiple layouts for large local files, showing you stuff really quickly and then streaming in content.  This means that the overall time will go up significantly, but the end result in most cases is that the UI is more responsive.

This could be a pathological case since it's a table, and we could be hitting performance bugs in incremental table rendering.

[David Kilzer (:ddkilzer)]

See also Bug 14917.

[David Kilzer (:ddkilzer)]

Reassigning back to webkit-unassigned.

[Eric Seidel (no email)]

Probably still worth profiling.  I don't see any intermittent problem.  Takes 5s to render on my retina MBP (using a slow connection to the interblags).

[Eric Seidel (no email)]

Should be trivial to just drop this file into PerformanceTests and run run-perf-tests --profile test.html.  If the sample looks reasonable than we should just close this bug.

[Eric Seidel (no email)]

I think any bugs to be found here are already covered by bug https://github.com/dglazkov/performance-tests.