116191 - nsZipArchive::ReadInit allocations

Status: RESOLVED FIXED

(Core :: General, defect, P2)

Description

[Suresh Duddi (gone)]

We read about 200 files from jars. ReadInit happens once for each of those.

ReadInit:
200 x 16 : 3,200 bytes
nZipRead() owned by nsJARInputStream
We could make this a member of nsJARInputStream as opposed to ptr And this
allocation would go away.

200 x <filesize> : 700k
  This entire buffer gets thrown away once necko chops this into 4k buffers and
fires OnDataAvailable(). Maybe we can pass this buffer out as a whole to
OnDataAvailable() and prevent all the chopping and churning.

Comment 1

[Suresh Duddi (gone)]

Attachment: Eliminate 200 16 byte allocs

Silly patch to make nsZipRead a member rather than a pointer. Doesnt save much
: about 3k and about 200 allocs.

Comment 2

[Suresh Duddi (gone)]

Marking P2 'cause of the 200 x <filesize> allocation

Comment 3

[Suresh Duddi (gone)]

*** Bug 116192 has been marked as a duplicate of this bug. ***

Comment 4

[Darin Fisher]

Comment on attachment 62329 [details] [diff] [review]
Eliminate 200 16 byte allocs

r=darin

Comment 5

[Darin Fisher]

sharing the 200 x <filesize> allocations with necko is going to be difficult.

it will be difficult to arrange for the jar buffer to be passed out to necko. 
instead, what about deferring the complete decompression until necko calls Read
on the jar input stream.  that way you could decompress the jar file directly
into the necko supplied buffer.  doing so would not require any api
modifications and would possibly yield even better results since there would no
longer be 200 <filesize> buffer allocations at startup.  these would all be
replaced with more allocator-friendly 4k buffers.

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 62329 [details] [diff] [review]
Eliminate 200 16 byte allocs

sr=dveditz

Comment 7

[Daniel Veditz [:dveditz]]

Uncompressing in chunks gets tricky and potentially expensive in a
multi-threaded app, and we know we get contention on these files because we used
to get failures until we put the locks around ReadInit() and other nsJAR methods.

That doesn't mean it's impossible, but nsZipArchive() might need a bit of a
re-write to handle it and we'll have to watch the performance implications
carefully.

Comment 8

[Suresh Duddi (gone)]

----------------------------
revision 1.62
date: 2001/12/21 05:57:32;  author: dp%netscape.com;  state: Exp;  lines: +5 -23
bug 116191 Making nsZipItem a member of nsJarInputStream rather than a
pointer. Saves a 16 byte allocation on per jar file read. r=darin, sr=dveditz
----------------------------