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.
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.
gagan: can you r= this patch?
Comment on attachment 61673 [details] [diff] [review] v1.0 patch WriteSegmentFun? :-) That the best you could come up with?... r=gagan
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
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?
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.
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.
Antonio.Xu: what is your page load test? this would only effect pages w/ external css or js files.