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.
Silly patch to make nsZipRead a member rather than a pointer. Doesnt save much : about 3k and about 200 allocs.
Marking P2 'cause of the 200 x <filesize> allocation
*** Bug 116192 has been marked as a duplicate of this bug. ***
Comment on attachment 62329 [details] [diff] [review] Eliminate 200 16 byte allocs r=darin
Attachment #62329 - Flags: review+
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 on attachment 62329 [details] [diff] [review] Eliminate 200 16 byte allocs sr=dveditz
Attachment #62329 - Flags: superreview+
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.
Summary: nsZipArchive allocations → nsZipArchive::ReadInit allocations
---------------------------- 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 ----------------------------
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.