466578 - Speed up XBL parsing

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[(dormant account)]

This should shave off another 100-200ms off startup time. However, i can't conclusively show that startup is faster due it varying by +-250ms here.

To get the number I timed the runtime of individual functions loading xbl files and those show a conclusive speed up. Larger xml files parse 2x faster now with no measurable slowdown on smaller ones.

Comment 1

[(dormant account)]

Attachment: reduce reads

Comment 2

[(dormant account)]

Attachment: single read (fixed typo)

Comment 3

[(dormant account)]

Just to give a bigger picture. Without my changes these files parse in about 610ms.

Comment 4

[(dormant account)]

Comment on attachment 349881 [details] [diff] [review]
single read (fixed typo)

my only concern here is the arbitrary maximum size

Comment 5

[Boris Zbarsky [:bzbarsky]]

So this just helps because we thrash around less in networking-parser-networking?  Or something else?  That is, what made you make this change?

The change itself looks ok, with PR_UINT16_MAX used for the magic constant.

Are there other places where we could get similar wins?  I guess XUL is fastloaded, so not an issue there....

Comment 6

[(dormant account)]

Actually IO and system calls in general on n810 are really slow. So this might be caused by that. Either that or each call into the parser is expensive, I'm not sure. I tried this from past experience indicating that parsing things in a big chunk is quicker than smaller incremental parses.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Perhaps we should consider increasing buffer sizes throughout necko from 4k to something bigger (16k?).  File followup bugs as needed?

Post a patch with PR_UINT16_MAX?

Comment 8

[(dormant account)]

Attachment: single read(added constant) [Checkin: Comment 11 & 12]

So I poked around some more. There is a superficially similar pattern in the CSSLoaderImpl::LoadSheet (according to oprofile callgraph) that's eating a few ms of start time. Fortunately css is less bloated than XML and increasing the buffers willy-nilly is either puny gain or a small performance loss.

So increasing buffers everywhere seems like it would hurt more unless those buffers will get used.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 350032 [details] [diff] [review]
single read(added constant)
[Checkin: Comment 11 & 12]

OK, let's do it.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 350032 [details] [diff] [review]
single read(added constant)
[Checkin: Comment 11 & 12]

a191=beltzner

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Pushed fc47c2c3e3c1

I guess this is still checkin-needed for 1.9.1

Comment 12

[Serge Gautherie (:sgautherie)]

Comment on attachment 350032 [details] [diff] [review]
single read(added constant)
[Checkin: Comment 11 & 12]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/bed2112e43b6