Closed Bug 313575 Opened 19 years ago Closed 19 years ago

unnecessary qi's to nsISeekableStream from nsFastLoadFile

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bryner, Assigned: bryner)

Details

(Keywords: perf)

Attachments

(1 file)

nsFastLoadFileReader/Writer/Updater repeatedly QI the input and/or output stream to nsISeekableStream.  In many cases this happens even if no seek is required for the read being performed.  We can optimize this by QI'ing to nsISeekableStream when the input or output stream is set and keeping the pointer around.  We can also take advantage of the fact that the underlying nsBinaryInput/OutputStream is keeping a similar cached interface pointer for nsIStreamBufferAccess.
Attached patch patchSplinter Review
Attachment #200587 - Flags: superreview?(brendan)
Attachment #200587 - Flags: review?(brendan)
Comment on attachment 200587 [details] [diff] [review]
patch

Nice, I was severely COMtaminated when I wrote fastload.  Nit:

>@@ -556,6 +568,8 @@ class nsFastLoadFileUpdater
> 
>   protected:
>     nsCOMPtr<nsIInputStream> mInputStream;

Blank line here to match style elsewhere in both existing file and your added members in reader and writer.

>+    // Kept in sync with mInputStream to avoid repeated QI
>+    nsCOMPtr<nsISeekableStream> mSeekableInput;
> };
> 
> NS_COM nsresult

Thanks,

/be
Attachment #200587 - Flags: superreview?(brendan)
Attachment #200587 - Flags: superreview+
Attachment #200587 - Flags: review?(brendan)
Attachment #200587 - Flags: review+
checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: