Re: Why is java.io.FileInputStream.readBytes my performance bottleneck

Discussion in 'Java' started by David Zimmerman, Jul 21, 2003.

  1. Harald Kirsch wrote:
    > With my new regular expression package featuring real
    > deterministic finite automata, I can do non-trivial work
    > and still find that java.io.FileInputStream.readBytes
    > seems to be the bottleneck. I run my program with
    >
    > java -Xrunhprof:cpu=samples
    >
    > and get output like this:
    >
    > ...
    > CPU SAMPLES BEGIN (total = 4377) Mon Jul 21 18:20:42 2003
    > rank self accum count trace method
    > 1 40.32% 40.32% 1765 187 java.io.FileInputStream.readBytes
    > 2 20.29% 60.61% 888 188 sun.nio.cs.StreamDecoder.read0
    > 3 18.12% 78.73% 793 190 java.nio.CharBuffer.wrap
    > 4 2.22% 80.95% 97 186 jfa.ArrayCharTrans.getPos
    > 5 1.78% 82.73% 78 193 jfa.Dfa.match
    > ...
    >


    > Note, however, the large distance to readBytes. How can a native
    > method like this take so much time? Is it possible that Xrunhprof
    > is somehow mislead by a native method?
    >


    When readBytes() hangs waiting for IO, all the time gets credited to
    readBytes().
     
    David Zimmerman, Jul 21, 2003
    #1
    1. Advertising

  2. David Zimmerman <> wrote:
    > Harald Kirsch wrote:
    > > With my new regular expression package featuring real
    > > deterministic finite automata, I can do non-trivial work
    > > and still find that java.io.FileInputStream.readBytes
    > > seems to be the bottleneck. I run my program with
    > >
    > > java -Xrunhprof:cpu=samples
    > >
    > > and get output like this:
    > >
    > > ...
    > > CPU SAMPLES BEGIN (total = 4377) Mon Jul 21 18:20:42 2003
    > > rank self accum count trace method
    > > 1 40.32% 40.32% 1765 187 java.io.FileInputStream.readBytes
    > > 2 20.29% 60.61% 888 188 sun.nio.cs.StreamDecoder.read0
    > > 3 18.12% 78.73% 793 190 java.nio.CharBuffer.wrap
    > > 4 2.22% 80.95% 97 186 jfa.ArrayCharTrans.getPos
    > > 5 1.78% 82.73% 78 193 jfa.Dfa.match
    > > ...
    > >

    >
    > > Note, however, the large distance to readBytes. How can a native
    > > method like this take so much time? Is it possible that Xrunhprof
    > > is somehow mislead by a native method?
    > >

    >
    > When readBytes() hangs waiting for IO, all the time gets credited to
    > readBytes().


    Well, looking at top, my cpu is 100% occupied by this, which means
    there is no waiting --- except java.io.FileInputStream.readBytes does
    idle waiting on Linux. Huuuuh, scaring.

    Harald.
     
    Harald Kirsch, Jul 22, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Glenn

    Performance Bottleneck in ASP.NET

    Glenn, Jan 8, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    591
    Glenn.
    Jan 8, 2004
  2. Roedy Green
    Replies:
    6
    Views:
    3,330
    Steve Horsley
    Jul 23, 2003
  3. Krick
    Replies:
    2
    Views:
    14,376
    Marco Schmidt
    Aug 28, 2003
  4. JLM
    Replies:
    2
    Views:
    1,494
  5. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,271
    Smokey Grindel
    Dec 2, 2006
Loading...

Share This Page