Many nested BufferedInputStream's - what's the impact?

There's a common pattern, when each layer of application, dealing with data from a stream tends to wrap it into a BufferedInputStream, so that at a whole, there's a lot of buffers, filled from buffers, filled from buffers 开发者_运维技巧and so on.

I think this is bad practice and want to question: how does it impact the performance? Can this cause bugs?

---

This is a very general question, but I'd say there are a number of problems with having lots of layers of buffered input streams (in any language).

• Each buffer takes up memory, even when it's not filled. So, even if the data gets sucked right up to the top "layer" straight away, memory is still being needlessly used. (Note: I'm assuming that Java doesn't resize its buffers automatically or anything — and I'm no Java expert.)
• Whenever you read from the top-level buffer, you'll be setting off a big chain of method calls. Method calls involve indirection (i.e. pointer-following), passing-around of data (which could lead to poor caching performance), and so on.
• It probably means that the design isn't very well-thought-out, since buffered streams should generally be for reading from sources that actually need buffering, like the disk or the network.

Just a few thoughts on the matter. I'm sure someone with better Java knowledge could contribute a more detailed analysis.

---

It will increase memory footprint due to the extra buffers, but I suspect its rare given the sizes likely involved that it will actually have a significant effect on a given program. Theres the standard rule of not trying to optimise before you need to.

Theres also bound to be a slight processor overhead, but this will be even less significant.

It all depends just how much it is used, if there are many large chains it could be a problem, but I think it unlikely to be a problem.

As David said it is likely an indication of poor design It would probably be more efficient for components to be able to share more complex objects directly, but its all down to specific uses (and I'm having trouble thinking of a reason that you would use multiple buffered streams in such a way).

---

It is indeed very bad practice and can indeed cause bugs. If method A does some reading and then passes the stream to method B which attaches a BufferedInputStream and does some more reading, the BufferedInputStream will fill its buffer, which may consume data that method A is expecting to be still there when method B returns. Data can be lost by method B's BufferedInputStream reading ahead.

As regards overheads, in practice, if the reads/writes are large enough, the intermediate buffers are bypassed anyway, so there isn't nearly as much extra copying as you might think: the performance impact is mostly the extra memory space plus the extra method calls.