stream loader optimizations

RESOLVED FIXED in mozilla0.9.8

Status

()

Core
Networking
P3
normal
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

({perf})

Trunk
mozilla0.9.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ready to land])

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
noticed that nsStreamLoader does a couple things that could be improved:

1) nsStreamLoader::OnDataAvailable calls Read instead of ReadSegments on the
input stream, resulting in an extra buffer copy.

2) nsStreamLoader::OnDataAvailable simply appends to mData, which is a
nsCString.  I noticed that at startup there are a number of CSS and JS files for
which OnDataAvailable is called several times.  The result is several
reallocations of mData.  This can be avoided by preallocating mData in
OnStartRequest to a size equal to the expected content length.  This requires
modifications to the JAR channel since it does not expose the content length of
the JAR item.

I'm not sure how much of a performance cost these things are... my initial
evaluation under Linux didn't show much of an improvement.  I'm hoping that
Win2k will show otherwise.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: perf
Priority: -- → P3
Target Milestone: --- → mozilla0.9.8
(Assignee)

Comment 1

16 years ago
Created attachment 61673 [details] [diff] [review]
v1.0 patch

this patch gave me a 0.9% startup improvement, and a 0.5% page load improvement
on win2k.
(Assignee)

Comment 2

16 years ago
gagan: can you r= this patch?

Comment 3

16 years ago
Comment on attachment 61673 [details] [diff] [review]
v1.0 patch

WriteSegmentFun? :-) That the best you could come up with?... r=gagan
Attachment #61673 - Flags: review+
(Assignee)

Updated

16 years ago
Blocks: 7251
Comment on attachment 61673 [details] [diff] [review]
v1.0 patch

+    if (NS_SUCCEEDED(rv))
+	 (*aInputStream)->Available((PRUint32 *) &mContentLength);

Do we know that Available returns the jar member's content-length, always?

/be
Attachment #61673 - Flags: superreview+
(Assignee)

Comment 5

16 years ago
brendan: yes... or at least that is how it is currently implemented.  available
returns the "real size" of the zip archive segment.

dveditz: can you double check this?
(Assignee)

Updated

16 years ago
Whiteboard: [ready to land]
Available() will return what's left of the data in the jar member. Before the
first read this will always be the full uncompressed size of the member.
(Assignee)

Comment 7

16 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 8

16 years ago
I found when i add this patch,on my source,then build on solaris,my mozilla 
page loading speed change slower.so i suggest we should research it.
(Assignee)

Comment 9

16 years ago
Antonio.Xu: what is your page load test?  this would only effect pages w/
external css or js files.
You need to log in before you can comment on or make changes to this bug.