1. Open the attached html using webkit r78249 or later. Try the same for: * Safari 5.0 * WebKit trunk r78794 or before * Any version of Chrome Notice how it is 10x slower than all others, where a pass (after the first dozen passes) takes >1000ms, rather than <100ms as other browsers do.
There is no test case attached at the moment, please attach it.
Created attachment 86471 [details] Test case Really attach the test case.
<rdar://problem/9169336>
Initial times are even (between Safari 5.0.3 and TOT), but TOT starts to skyrocket upward from there. Safari 5.0.3 does have one or two very long pauses on the order of TOT, but TOT has very long pauses during each iteration.
Safari 5.0.3 beginning: [A] Last pass took 43ms [A] Last pass took 48ms [A] Last pass took 65ms [A] Last pass took 30ms [A] Last pass took 31ms [A] Last pass took 101ms TOT beginning: [A] Last pass took 52ms [A] Last pass took 58ms [A] Last pass took 60ms [A] Last pass took 69ms [A] Last pass took 84ms [A] Last pass took 95ms TOT later: [A] Last pass took 1119ms [A] Last pass took 1153ms [A] Last pass took 1168ms [A] Last pass took 1184ms [A] Last pass took 1200ms [A] Last pass took 1215ms
Created attachment 87197 [details] Patch
Committed r82162: <http://trac.webkit.org/changeset/82162>
Reopening, since my patch didn't fix the whole regression.
Updating title to reflect the specific constraints of this test: it allocates a 2GB tree! Most of the run-time is dominated by OS virtual memory allocation, fault, and zero fill calls.
Some regression ranges: 77699 (fast) - 80051 (slow) [actually 78312] -> The capacity() bug, which was fixed in <http://trac.webkit.org/changeset/82162>. 80051 (fast) - 80052 (slow) -> Changing the block size to 16KB.
Testing in other browsers: Firefox aggressively grows the heap to 2GB, and never shrinks it. This is the fastest possible policy for this stress test (~2s total), but a very bad policy for memory footprint! Chrome is pretty fast (~3.5s total) on its first run, but gets very slow (>30s total or complete hang) on later runs.
> Firefox aggressively grows the heap to 2GB, and never shrinks it. Correction: It looks like Firefox will eventually shrink from 2GB if you give it enough cajoling.
It looks like the fundamental underlying problem here is that vm_map is O(N^2).
Comment on attachment 87197 [details] Patch Clearing review flag to get this out of the list.