Bug 14917 – 20x load performance regression on 700k table

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Samuel Allen]

The existing attachment from a bug I filed two years ago (in the URL field above) is basically a total disaster now in the performance realm. I haven't tested on Mac but this 700k page shows horrible performance on Windows WebKit (ToT and Safari 3.0.3). 

The behavior I am seeing is that WebKit uses about 20x more CPU time when loading this page off of the network than it does when loading off of the hard disk. (The times are over 3 seconds of CPU time from the network, and 0.15 seconds CPU time loaded from the disk.)

I do not know if this problem is specific to the Windows WebKit. I haven't tested on Mac OS X. I have a fast Internet connection so the page should load about as fast on the Internet as it does from the disk. I am using Vista and haven't tested XP. 

The issue is with attachment 3234 [details]. As an aside, Safari crashed when I tried to load this page in a new tab on one of the test runs, but I haven't been able to reproduce that.

[Geoffrey Garen]

Samuel, thanks for the bug report. I have a few questions:

- What is this regression relative to? Do you have numbers from an older version of WebKit?
- What does "CPU time" mean? Is it anything user-visible?

Are you just reporting that the page does more overall CPU processing when loaded from the network? That's not surprising. Network loads are asynchronous, so they provide more opportunities for incremental layout during the load, which would use CPU.

[Samuel Allen]

I have a screenshot of the Performance Monitor on Windows Vista. There are two lines on the graph: the green line is the network utilization, and the red line is the processor utilization. Due to the fact that I have 4 cores on my PC, a single thread running will push the percent CPU usage up to 25%. 

When I load the page in Safari from Bugzilla, the network utilization spikes for a couple seconds and then returns to zero. The processor time goes to 100% for about 10 seconds, including the two seconds in which the page is downloaded. 

The right side of the graph shows the CPU usage when the document is loaded from the disk. There is no network activity (no green) and the CPU is maxed out for perhaps 1 second. 

During the ten seconds in which one core is at 100% (when the page is loaded from the network), Safari is unresponsive and unusable. On my 2.4 GHz Core 2, I even get the spinning cursor. 

So what I appear to be seeing is that Safari takes 8 seconds to render a page after it has been retrieved from the network, and less than 1 second to render the page from the hard disk. I don't know if the fact that Safari freezes during those 8-10 seconds is a separate bug or somehow related.

I might be wrong about the regression label because I am comparing the behavior from 2 years ago on the Mac to the behavior today on the PC. This might be a Windows-only problem instead of a regression. 

Other browsers on Windows do not display this behavior. Firefox takes 3-4 seconds of CPU usage to display the table from the network and from the disk. 

[Samuel Allen]

Created attachment 15891 [details]
Performance Monitor screenshot

[Samuel Allen]

I just checked the testcase in Safari 3.0.3 on a Mac mini 1.42 GHz running OS X 10.4. The Mac does not show this bug. The testcase renders very quickly and none of the unresponsiveness occurs. 

So I guess this is a Windows-only bug. It is probably wrong to say it is a regression, as it probably never did work right on the platform. 

Here are some of the times the page reports:

Windows Vista
From hard drive: 0.15 seconds
From network: 3-6 or more seconds, unresponsive

Tiger
From hard drive: 1.4 seconds
From network: 1.4 seconds

[David Kilzer (:ddkilzer)]

(In reply to comment #0)
> The issue is with attachment 3234 [details] [edit]. As an aside, Safari crashed when I tried to
> load this page in a new tab on one of the test runs, but I haven't been able to
> reproduce that.

This attachment is from Bug 4296.

[Robert Blaut]

It's the same issue as described in bug 14918.

*** This bug has been marked as a duplicate of 14918 ***