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....
Created attachment 3234 [details]
This might only show the problem when you load the file from the hard disk directly.
This occurs much less often in recent builds of WebKit, but after enough tries I can still reproduce the 4-
second load time.
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.
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.
See also Bug 14917.
Reassigning back to webkit-unassigned.
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).
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.
I think any bugs to be found here are already covered by bug https://github.com/dglazkov/performance-tests.