RichardC (tich.delete@this.pobox.com) on May 15, 2013 2:00 pm wrote:
> Ricardo B (ricardo.b.delete@this.xxxxx.xx) on May 15, 2013 1:40 pm wrote:
> > > I've used Core i5 and now a 6-core Intel. I still find some webpages rather clunky
> > > (I think mostly those with lots of javascript). These days, processing a webpage very
> > > often involves running a pretty complex JS program.
> >
> > That JS can be fetching stuff from the network (AJAX, etc) though...
> >
> > Can you provide an example of such page? Can you run a JS CPU profile on them?
>
> http://www.fudzilla.com
> http://www.boston.com
>
> Each take a couple of seconds (on i7). Which maybe some people wouldn't mind, but I want
> the complete page within 0.5 sec.
>
> For fudzilla.com, JS profile shows 651mS program time. So I guess the 2 sec isn't all
> execution time, but then that 651mS on its own is too much for me.
>

On my iMac (quad IB with HT) using Safari, the first rendering of both these pages took around 2 seconds, but was very obviously throttled by crappy server side latency --- not network bandwidth, not CPU. Subsequent renderings (where images and suchlike could be pulled from either local cache or my proxy cache) were about .5 sec or less.

Same experience with Chrome (which suggests the proxy cache wasn't capturing much, it was local cache doing all the work).

The work involved for such a page is split over three main processes, the Safari engine, the Safari UI, and a Flash process. Each hit a maximum of about 30% of CPU.

I conclude that it is unrealistic (at least for THESE pages) to conclude that CPU on a desktop is much responsible for the delay. The real problem seems to be a crappy server side that doesn't seem to much care about synching its page with its assets to ensure that everything is served up with minimal latency.

More interesting (IMHO) is a page like Facebook. That seems to do a better job with the server-side latencies, but the heavy JS (or PHP translated into client-side JS, or whatever the fsck Facebook is using these days) means that both Safari and Chrome hit a peak of about 75% CPU usage as they parse the page. Safari also peaks at around 75% when scrolling the page rapidly up and down, and the scrolling is jerky, but that's a known Safari bug, supposedly fixed in the nightlies, and not really proof of anything. Chrome scrolls the same page smooth as butter --- but still uses about 45% of a CPU to do so.

My overall experience is that on this IB machine (unlike my earlier Penry) and with a 50Mb/s connection (and a Fusion drive, so SSD) I just don't see CPU as ever the real cause of slow web pages --- the cause is pretty much always crappy pages with high server side latency. Where one DOES want multi-threaded handling of a page is on mobile, where it IS obvious that the CPU is sometimes the bottleneck in rendering.