Closed Bug 12346 Opened 21 years ago Closed 20 years ago

nsOutputFileStream should buffer the output

Categories

(Core :: Editor, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dmose, Assigned: dougt)

Details

Attaching with strace(1) reveals that writes are not being buffered in any
useful way.  Example output from strace:

write(20, "=", 1)                       = 1
write(20, "\"", 1)                      = 1
write(20, "http://bugzilla.mozilla.org/show"..., 48) = 48
write(20, "\"", 1)                      = 1
write(20, ">", 1)                       = 1
write(20, "3256", 4)                    = 4
write(20, "<", 1)                       = 1
write(20, "/", 1)                       = 1
write(20, "a", 1)                       = 1
write(20, ">", 1)                       = 1
write(20, ": Add ScrollIntoView() method to"..., 52) = 52
write(20, "<", 1)                       = 1
write(20, "/", 1)                       = 1
write(20, "td", 2)                      = 2
write(20, ">", 1)                       = 1
write(20, "<", 1)                       = 1
write(20, "/", 1)                       = 1
write(20, "tr", 2)                      = 2
write(20, ">", 1)                       = 1
The save code passes an nsIOutputStream to the content sink, and the
nsHTMLContentSinkStream calls Write() with lots of small chunks on this output
stream. The stream does not buffering, so perhaps it should?

Alternatively, the nsHTMLContentSinkStream could buffer each line of outout.
Status: NEW → ASSIGNED
Target Milestone: M10
I'll make the output sink buffer its output in the stream case (it already
buffers the whole file in the nsString case).
Line buffering turns out not to be straightforward, since
nsHTMLContentSinkStream::Write can take an nsString, a char* or a char.  So I'll
probably just write when it reaches some number of characters.
That seems better anyway, since line buffering would still often end up with one
write() per < 80 chars, which still seems like too many.
The alternative (which is the Right Thing, IMO) is to make nsOutputFileStream
do buffering. Then everyone gets buffering. I don't know who owns this now.
Turns out that would really be much better.  Buffering in the HTML content sink
stream turns out to be tricky because of the way it does different unicode
conversions in the three different Write() methods.
Assignee: akkana → dougt
Status: ASSIGNED → NEW
Summary: "save as" in editor performs very poorly → nsOutputFileStream should buffer the output
Adjust summary, reassign.
Target Milestone: M10 → M11
not happening for m10, moving to m11.
Status: NEW → ASSIGNED
looking at this now.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
just checked in.  Buffer is 4k.
I need help verifying this bug and marking it VERIFIED-FIXED...any takers?
Should be pretty easy; on linux:

1) go to a large web page
2) edit the page
3) attach to the apprunner process with strace(1), using -o to save the output
   to a file
4) save the page
5) look at the strace output and make sure that the calls to write() are using
   large (4K) buffers rather than 1 and 2 byte buffers as shown above
Status: RESOLVED → VERIFIED
verified in 9/9 build.
You need to log in before you can comment on or make changes to this bug.