This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 117426

Summary: CachedInputStream is slow
Product: platform Reporter: Petr Nejedly <pnejedly>
Component: FilesystemsAssignee: rmatous <rmatous>
Status: RESOLVED FIXED    
Severity: blocker CC: issues, pjiricka
Priority: P3 Keywords: PERFORMANCE
Version: 5.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on:    
Bug Blocks: 114195    
Attachments: pathc for read impl.

Description Petr Nejedly 2007-10-02 11:58:51 UTC 
CachedInputStream implements only single-byte read method, and while a bunch of sniffing resolvers could end up doing
just a bunch of arraycopy()s, they instead always go through complicated caching logic for each byte they require.
We currently have 12 magic-based mime resolvers that end up doing 186 single-byte read operations on the underlaying
stream, and that is for each recognized file in a folder.
In my profile, the IDE consumed 2s in mime resolution of 120 java files, 1s (out of that 2s) just in the
CachedInputStream. (22056 calls in total).

You need to implement the bulk read method.
Comment 1 Petr Nejedly 2007-10-02 12:07:14 UTC 
... an I don't want to know what will happen with xml sniffing mime resolvers, which tend to process much larger chunks
of data.

This bug should be quite simple to fix.
Comment 2 Petr Nejedly 2007-10-02 12:33:42 UTC 
Need more profiling. It might be the case that although the single byte read() gets called many times, the time is
actually spent in the underlaying JDK+native read method (clod caches).
Anyway, it won't hurt to have read(byte[], int, int) implemented, it's just 10 or so lines of code.
Comment 3 rmatous 2007-10-03 09:59:29 UTC 
Created attachment 50066 [details]
pathc for read impl.
Comment 4 Petr Nejedly 2007-10-03 10:47:00 UTC 
The patch is OK though a bit confusing:
int buflen = Math.max(len, blen);
buflen = (buflen > 0) ? (buflen * 2) : 256;
It works only because pos is never more than len.
I would expect the first line would read "int buflen = pos+blen" (which is always more than len)
and the second line can never take the ":256" branch anyway. Well, it can, if len=0 and blen=0, but such case (just for
correctness, I don't expect anybody calling it this way) should be covered by the initial if, which should, in fact read
boolean isCached = (pos + blen <= len); // less or EQUALS

I'd refactor the buffer refill into a separate routine used from both read methods, though.
Comment 5 rmatous 2007-10-03 17:36:27 UTC 
/cvs/openide/fs/src/org/openide/filesystems/MIMESupport.java,v  <--  MIMESupport.java
new revision: 1.23; previous revision: 1.22

Patch slightly modified and fixed.
Comment 6 rmatous 2007-10-04 13:34:08 UTC 
Rollback - reopened
Comment 7 rmatous 2007-10-04 18:29:47 UTC 
/cvs/openide/fs/src/org/openide/filesystems/MIMESupport.java,v  <--  MIMESupport.java
new revision: 1.25; previous revision: 1.24