What's the fastest input stream reader?

Question

Here's my candidate for the fastest stream reader. My interest and testing is with file input streams, but it's nice to support any stream.
     public static String readStream(InputStream is) throws IOException{
          int i, length = 0;
          StringBuffer s = null;
          char[] c = null;
          InputStreamReader isr = new InputStreamReader(is);
          while(length != -1){
               length = is.available();
               if(c == null) c = new char[length];
               isr.read(c, 0 , length);
               i = isr.read();
               if(i == -1){
                    if(s == null) return String.copyValueOf(c);
                    else break;
               }else{
                    if(s == null) s = new StringBuffer();
                    s.append(c, 0, length);
                    s.append((char)i);
          return s.toString();
     }

Answer 1

I do have a separate function that's optimized for file reading. I have tried the simpler implementation, and it is slower.
The reason I'm reading into a StringBuffer is that I have a DOM framework that allows you to load an xhtml document, do stuff, and then print out the result. I have Styles which allow you to merging a document with a style document and then in your project specific code, modify the resulting document. In one case, my style document is located on a remote machine and has the following:
<link rel="stylesheet" href="<!--SOURCEURL-->style.css" type="text/css" media="all"/>
I allow the Style class to override a "replaces" function that does string replacements and thus allows the non-xml compliant comment to be replaced by the appropriate URL prefix for the remote machine. I admit this probably isn't the best way to do it, since the comment makes the document invalid. I'd like to change to a better way, but I'd still like to keep the option of doing textual replaces on the input document before loading it into DOM. This may be a requirement since it is the convension that was previously used before we started using DOM.
As for bounded size, I figure the StringBuffer is going to be a lot smaller than the DOM representation anyway. And, neither should be that significantly large.