Closed Bug 19233 Opened 25 years ago Closed 25 years ago

factor buffering into separate stream class

Categories

(Core :: XPCOM, defect, P3)

All
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: warrensomebody)

Details

(Whiteboard: [PDT+] 02/04-Checking on verification with eng)

We should factor the buffering out of nsFileOutputStream and into a separate
filter stream, nsBufferOutputStream. nsBufferOutputStream should take another
stream to flush to when its buffer becomes full:

  NS_NewBufferOutputStream(nsIOutputStream* out, nsIOutputStream* *result);

(Do we need to do a similar thing for input streams?)
Target Milestone: M15
setting milestone.

we already have buffering in the file stream.  We should rip that out and use
this method instead.
reassigning to warren.
Assignee: dougt → warren
This needs to get done for beta now since all file i/o is now going through the 
new file streams we did for nsIFile, and that stuff isn't yet buffered. I've got 
some code in my tree for this.
Keywords: beta1
Target Milestone: M15 → M14
PDT agrees that buffered I/O is good. PDT+
Whiteboard: [PDT+]
I just checked in some preliminary code for this. It lives in 
netwerk/base/public/nsIFileStreams.idl right now. Made the file transport use 
it. It should speed up caching, and save-as, but I haven't noticed any 
improvements for reading files (e.g. chrome files). That time is dwarfed by 
lots of other things (0.03% of runtime).
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
So could this be marked as Verified as far as work done.  Or should this be open 
for more work?
Whiteboard: [PDT+] → [PDT+] 02/04-Checking on verification with eng
Mark it verified.
marking Verified per last comments...thanks! :-)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.