Poor performance by overriding Java class?

Question

I have the following class subclass of FilterInputStream with only one method overrided. However the performance of this class is so poor. It performs at 1/10 the speed of its superclass. I even took the same source code from InputStream of javasrc and used it in my subclass. Same performance hit. Is there something wrong with overriding classes?

public class NewLineStream extends FilterInputStream    {


public NewLineStream(InputStream in) {
 super(in);
}



public int read(byte[] b, int off, int len) throws IOException {  
 if (b == null) {
  throw new NullPointerException ();
 } else if ((off < 0) || (off > b.length) || (len < 0) ||
   ((off + len) > b.length) || ((off + len) < 0)) {
  throw new IndexOutOfBoundsException ();
 } else if (len == 0) {
  return 0;
 }

 int c = read();
 if (c == -1) {
  return -1;
 }
 b[off] = (byte)c;

 int i = 1;
 try {
  for (; i < len ; i++) {
   c = read();
   if (c == -1) {
    break;
   }
   if (b != null) {
    b[off + i] = (byte)c;
   }
  }
 } catch (IOException  ee) {
 }
 return i;
}

}

Answer 1

Yes, you read() one-by-one, if there is no underlying buffering going on, it will be really slow. Pass in a BufferedInputStream and it should speed up.

Answer 2

This method is reading byte-by-byte, I guess that's why it performs so poorly. FilterInputStreams usually are just wrapping other input streams, so if you're not going to do any filtering, just call read(byte[], int, int) on the wrapped stream.

Answer 3

Performance hits for overriding classes should be negligible for almost all purposes.

Perhaps the problem is in the InputStream you're decorating.

Answer 4

Is there something wrong with overriding classes?

no, it doesn't.

However FilterInputStream is just a decorator around the InputStream that you pass using the contructor. I would wrap my input stream around a buffered's one, like a BufferedInputStream:

NewLineStream nws = new NewLineStream(new BufferedInputStream(in));

Answer 5

Most of the time when developers feel they have found a bug in the JDK or how Java works, its usually just a misunderstand on the part of the developer. Java is more than ten years and most common bugs have been solved already.

There more than few bad design decisions lying around which are perhaps too difficult to fix now but I cannot think of any which impacts performance or doesn't have a known work around.