Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

Sybex CSG 11: What is the Real Advantage of Buffered Stream Classes Over Low-level Stream Classes?

 
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
On page 936 of the study guide, an answer is provided to the question about the real utility of Buffered stream classes, since the read() and write() methods of stream classes discussed in the book have overloaded versions that allow a programmer to write code that uses read() and write() methods that read/write blocks of byte or char types (into/from an array) at a time, as opposed to the read() and write() methods that only read/write one byte or char type at a time.

The discussion in the study guide, which provides an answer to this question, provides the following explanations:

(1.) "Put simply, the Buffered classes contain a number of performance improvements for managing data in memory. For example, the BufferedInputStream class is capable of retrieving and storing in memory more data than you might request with a single read(byte[]) call."

(2.) "For successive calls to the read(byte[]) method with a small byte array, using the Buffered classes would be faster in a wide variety of situations, since the data can be returned directly from memory without going to the file system."

The explanation in the point number 1 above suggests that, for example, the size of a block of data that a Buffered class is able to read/write from/to memory is greater than that, which a programmer is able to read/write, in code they write. However, as the code below shows, a programmer is able to write code using the FileReader and FileWriter classes, which are able to read/write blocks of data that are as large as those that the BufferedReader and BufferedWriter classes are able to. While it maybe true that the BufferedReader and BufferedWriter classes contain a number of performance improvements for managing data in memory, over the FileReader and FileWriter classes, doesn't the code below show that reading/writing larger data blocks from/to memory is not one of these performance improvements?

The explanation in the point number 2 above suggests that when, for example, the BufferedReader and BufferedWriter classes as well as the FileReader and FileWriter classes use a small buffer array, the BufferedReader and BufferedWriter classes read/write from/to memory, while the FileReader and FileWriter classes don't (so, for example, the FileReader and FileWriter classes read/write from/to the file system, instead). In this interpretation, which I have of the remark quoted in the point number 2 above, have I correctly understood the remark and, hence, is the suggestion, that the BufferedReader and BufferedWriter classes read/write from/to memory, while the FileReader and FileWriter classes read/write from/to the file system, actually correct?
 
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
&TLDR;, Yes.

I notice most of the relevant calls happen in Native code, so looking at them in Java Source isn't an option:


Of course one could disassemble the native .dll's or .so's.  But do we need to?
You could use ProcMon or similar Linux tools to count the low-level calls to the file system.

I have no reason to disbelieve that the Buffered Stream classes, both Reader/Writer and Input/OutputStream use the buffer sizes that you can create them with, and the default size, which is not specified, otherwise.

In general, a Writer sends its output immediately to the underlying character or byte stream. Unless prompt output is required, it is advisable to wrap a BufferedWriter around any Writer whose write() operations may be costly, such as FileWriters and OutputStreamWriters. For example,

PrintWriter out
  = new PrintWriter(new BufferedWriter(new FileWriter("foo.out")));

will buffer the PrintWriter's output to the file. Without buffering, each invocation of a print() method would cause characters to be converted into bytes that would then be written immediately to the file, which can be very inefficient.


Okay, you inspired me to look at the source code for BufferedWriter, which is in Java, and the buffer sizes are specified in characters, not in bytes...

I saw that if you happen to call the FileWriter with such a huge chunk at a time as to be larger than the buffer size, it doesn't waste time buffering pointlessly:
   /**
    * Writes a portion of an array of characters.
    *
    * <p> Ordinarily this method stores characters from the given array into
    * this stream's buffer, flushing the buffer to the underlying stream as
    * needed.  If the requested length is at least as large as the buffer,
    * however, then this method will flush the buffer and write the characters
    * directly to the underlying stream.  Thus redundant
    * {@code BufferedWriter}s will not copy data unnecessarily.
    *
    * @param  cbuf  A character array
    * @param  off   Offset from which to start reading characters
    * @param  len   Number of characters to write
    *
    * @throws  IndexOutOfBoundsException
    *          If {@code off} is negative, or {@code len} is negative,
    *          or {@code off + len} is negative or greater than the length
    *          of the given array
    *
    * @throws  IOException  If an I/O error occurs
    */
   public void write(char cbuf[], int off, int len) throws IOException {

So what I saw in BufferedWriter is that you can create buffers of virtually any size and the class will only actually mess with the stream itself when you issue a flush or when you exceed the buffer size.  Until then, no interaction.  It is all just sitting there in memory, waiting for a flush, a close, or until the buffer is filled for any file system interaction.  It's the interaction with the stream that is costly, how much would depend on hardware, drivers, file system and OS variables, but a bunch.

You seem to be saying "Can't I do all the buffering myself by just using enormous buffers I prepare myself without using PrintStream/PrintWriter methods?"

Maybe, but the whole point of these is to insulate your code that is writing data out / reading it in from those factors.  Your application should be thinking in terms of higher-level concerns and let the various BufferedWhatever classes do the buffering for you.

I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.  Probably similar for reading.  But that would be pathological for many applications.  You want to be making higher level calls that aren't worrying about that most of the time, and letting the Buffered classes do that work for you.
 
Marshal
Posts: 26697
81
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Nyeng Gyang wrote:The explanation in the point number 1 above suggests that, for example, the size of a block of data that a Buffered class is able to read/write from/to memory is greater than that, which a programmer is able to read/write, in code they write. However, as the code below shows, a programmer is able to write code using the FileReader and FileWriter classes, which are able to read/write blocks of data that are as large as those that the BufferedReader and BufferedWriter classes are able to.



You're correct that a programmer can read/write from a Buffered class just as much as that class stores in its memory buffer. But the study guide doesn't say otherwise. What it says, according to you (and you have a copy of the guide at hand) is:

The study guide wrote:For example, the BufferedInputStream class is capable of retrieving and storing in memory more data than you might request with a single read(byte[]) call.



So, that doesn't say anything about the programmer's ability. It only says something about the programmer's possible actions. For example the programmer might write code which reads one byte at a time from a BufferedInputStream.

Historically the Buffered classes were written because buffering of input or output between memory and an external device was an essential optimization. In those old days a disk sector might have been 512 bytes, so reading 512 bytes from a file was no more expensive than reading 1 byte from that file. But since accessing data from a disk took orders of magnitude longer than processing that data in memory, it was an obvious idea to read 512 bytes into a buffer and write a bit of code which interfaced your code with the data in that buffer. Even today the need for that sort of optimization has not gone away. I remember doing tests for the system I worked on in which I tried various buffer sizes for a BufferedReader to see which choice of buffer size would provide the greatest speedup. Yes, there was an answer because too-small buffers were ineffective and too-large buffers were wasteful.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Paul Clapham wrote:But the study guide doesn't say otherwise.


And, neither did I say the study guide says otherwise. Rather than my remark being about a Buffered class being able to read/write "just as much as that class stores in its memory buffer," as you said, my remark is about a comparison of the size of data that the FileReader and FileWriter classes are able to read/write vs. the size of data that the BufferedReader and BufferedWriter classes are able to read/write.

I believe that you have interpreted the sentence you quoted from the study guide as follows: For example, it is possible for the size, of the data that the BufferedInputStream retrieves and stores in memory, to be greater than the size of data that you retrieve and store in memory with a single read(byte[]) call.

My understanding of the English word "may" (and, by extension, the word's past tense "might") is that, in addition to this word meaning "it is possible," as used in your interpretation (furnished above) of the sentence you quoted, the word can also mean "ability, as permitted." I rewrite the sentence you quoted, in the following two ways, in order to illustrate this understanding I have:

(1.) For example, the BufferedInputStream class is capable of retrieving and storing in memory more data than it is possible for you to request with a single read(byte[]) call.

(2.) For example, the BufferedInputStream class is capable of retrieving and storing in memory more data than you are able to request, as permitted, with a single read(byte[]) call.

While I can very easily see how your interpretation of the quoted sentence is appropriate, you have to take a step back and obtain the big picture of an explanation in discussion the authors provide in the book. This sentence is given in the middle of providing an answer to the following question: What is the real utility of Buffered stream classes, since the read() and write() methods of stream classes discussed in the book have overloaded versions that allow a programmer to write code that uses read() and write() methods that read/write blocks of byte or char types (into/from an array) at a time, as opposed to the read() and write() methods that only read/write one byte or char type at a time?

If we use your interpretation of the quoted sentence, we are then left wondering how the discussion in the study guide, which suggests that it is providing an answer to the question mentioned in the preceding paragraph, actually answers this question. In particular, since your interpretation of this sentence means that reading/writing larger of data blocks from/to memory is not one of the performance improvements that the BufferedReader and BufferedWriter classes have, over the FileReader and FileWriter classes, for managing data in memory, what are these performance improvements? While it is clear that discussion in the study guide covers your explanation for the need of buffering data (in memory caches), as well as the need to determine an optimal buffer size, I really don't see how the discussion in the study guide answers this question.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:You seem to be saying "Can't I do all the buffering myself by just using enormous buffers I prepare myself without using PrintStream/PrintWriter methods?"


Yes, this is the question that the discussion in the study guide suggests it is addressing, but doesn't seem to actually answer. The answer to the question seems to be provided in the following remark you made:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.  Probably similar for reading.

 
Paul Clapham
Marshal
Posts: 26697
81
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Well, you're wasting your time asking me. I don't have a copy of the book so discussing my interpretation of sentences which you took out of context is pointless, as is your lecture on fine points of the English language.
 
Jesse Silverman
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
There are two layers here.

In general, your application shouldn't be thinking about buffering and such where it is doing its reads and writes.
It is busy enough getting all the logic correct.

BufferedReader and BufferedWriter ensure that the actual reads and writes only occur relatively infrequently regardless of what your specific read/write/print calls are.

Where it actually matters, you can explicitly flush to get past this.

By saying that you could just always make calls to an underlying writer or reader of that buffer size, you are essentially taking on the buffering responsibility yourself!
The reason that BufferedReader and BufferedWriter were provided to us was to free us from that responsibility.

So BufferedReader and BufferedWriter are performing the following service:
Minimizing expensive interactions with the platform's/OS's IO subsystem, de-coupling your application code from having to worry about that, except to manually flush when you think it makes a difference.

You can ignore them at the cost of essentially pointlessly implementing them yourself, only ever calling the underlying Reader/Writer to get or emit a full buffer.

If your code is just thinking about its logical needs, reading and writing whatever it needs at that moment, then if it is making the calls to BufferedReader/BufferedWriter the expensive OS interactions are all kept to a minimum.  If not, then either every single read and write call you make interacts with the OS, or you are pointlessly duplicating their logic in order to do it yourself.  The point of the text in the book was not to suggest that you couldn't do such a thing, obviously you could copy the code from the java.io classes and just name them MyBufferedReader and MyBufferedWriter.

In general, normally coded Java IO will work much more efficiently using the provided BufferedReader/BufferedWriter classes.  If you go out of your way to come up with code that won't benefit from that, it is because you are essentially re-doing the work yourself.  Your code would be more readable, maintainable and easier to work with had you just taken advantage of the classes they gave you.
 
Jesse Silverman
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Paul Clapham wrote:Well, you're wasting your time asking me. I don't have a copy of the book so discussing my interpretation of sentences which you took out of context is pointless, as is your lecture on fine points of the English language.



While I have the book, I think, at least if I hopefully answered his question on the last round there are two factors:
1. I am stubborn!
2. I am actively studying this material in a live manner.

It is possible that this section might possibly have been written slightly clearer, but when they say:

For example, the BufferedInputStream class is capable of retrieving and storing in memory more data than you might request with a single read(byte[]) call."



To me, it is clear that they mean the BufferedInputStream will be retrieving and storing in memory more data than your normally written code has any sane reason to request with a single call, unless you insist on ignoring the fact that Java wrote this class for you and feel you have to re-write its buffering logic for some reason unfathomable and seemingly pointless to most programmers.

This hasn't been a waste of time for me.  Literally every time I make use of the BufferedReader and BufferedWriter classes I will be even more glad I don't have to do all that crap myself.
I started programming as a kid in the 80's, so I used to have to do dang near everything myself.
Java does nearly everything for you!!
Complaining that it takes so dang (family-friendly-edit) long to learn all the stuff it is sitting there just waiting to do for you feels to me like complaining that your family has so many maids and butlers and gardeners that you can't remember all their names.  So I try to stop myself when I am doing that.  I don't mean to look the gift horse in the mouth.

I reflect on all the time I've spent learning Java stuff and still so much more to go...almost NONE of it is "dumb crap I will never use"...almost ALL of it is stuff I had to re-write for most of my life every time I got a new job, a hard-drive crashed, etc.

* * * end of rant * * *

For what its worth, I am pretty sure that the OP was just tripped up by the language used in the book, and to some extent I might have been fighting a straw man.  But the API is what I've been studying the past week, and had plenty of questions about BufferedReader and BufferedWriter along the way.  When I read the same lines, I felt I knew exactly what they meant, which is what I beat to death in way fewer words.
 
author & internet detective
Posts: 40677
827
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Besides, you should use File.write() and let Java take care of all that .
 
Jesse Silverman
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jeanne Boyarsky wrote:Besides, you should use File.write() and let Java take care of all that .



Did you mean Files.write() ??  I am trying to go NIO.2 wherever appropriate.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Paul Clapham wrote:Well, you're wasting your time asking me. I don't have a copy of the book so discussing my interpretation of sentences which you took out of context is pointless, as is your lecture on fine points of the English language.


You don't have to take this personal, since the question was not directed particularly at you, personally, but at all those who come across the question in this forum. Furthermore, rather than my having taken the sentence out of context, my discussion actually advises that your interpretation of the sentence, though very appropriate, is incongruent with the context in which it is provided.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:By saying that you could just always make calls to an underlying writer or reader of that buffer size, you are essentially taking on the buffering responsibility yourself!
The reason that BufferedReader and BufferedWriter were provided to us was to free us from that responsibility.


Except I have not properly understood the "responsibility," of which you speak in the foregoing remark you made, this "responsibility" is non-existent in the particular code example I provided above. In this example code I provided, there is zero extra effort taken to implement the code using the FileReader and FileWriter classes, instead of using the BufferedReader and BufferedWriter classes. If, as the discussion in the book advises, an effort needs to be exerted, in order to determine an optimal buffer size, whether some code implementation uses the FileReader and FileWriter classes or it uses the BufferedReader and BufferedWriter classes, I still haven't followed/understood either any extra benefit of using the buffered classes or the extra effort incurred from using the non-buffered classes.
 
Jeanne Boyarsky
author & internet detective
Posts: 40677
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:

Jeanne Boyarsky wrote:Besides, you should use File.write() and let Java take care of all that .



Did you mean Files.write() ??  I am trying to go NIO.2 wherever appropriate.


Yes, "Files"

I ❤️ NIO.2. It's very powerful.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:It is possible that this section might possibly have been written slightly clearer, but when they say ...


For me, it isn't so much that the quoted sentence is truly unclear as it is that the context, in which the sentence is provided, suggests that the performance improvements discussed in that section of the book are those very same ones that we have agreed are not performance improvements offered by the buffered classes (i.e., the buffered classes do not provide the performance improvements, over the non-buffered classes, of enabling a programmer to copy larger data chunks).
 
Jesse Silverman
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
(Muses): Am I super-patient or super-stubborn?  Is there an objective experiment that could be performed to tell the difference??

the context, in which the sentence is provided, suggests that the performance improvements discussed in that section of the book are those very same ones that we have agreed are not performance improvements offered by the buffered classes (i.e., the buffered classes do not provide the performance improvements, over the non-buffered classes, of enabling a programmer to copy larger data chunks).



If you use unbuffered I/O (which sometimes is required for certain purposes, there is a reason everything isn't buffered by default whether you ask for it or not) then:

If you read or write 8192 bytes at a time in one shot, Java will be transferring 8192 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read or write 2048 bytes at a time in one shot, Java will be transferring 2048 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read 128 bytes at a time in one shot, Java will be transferring 128 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read and write single characters, Java will be transferring one, two or four bytes in each (expensive) interaction it has with the Operating System and hardware.

So 8192 bytes of data written can mean somewhere between one and 8192 (expensive) interactions between Java and the Operating System and hardware.

If you Bite the Wax Tadpole and use BufferedReader/BufferedWriter, on the other hand:
If you read or write 8192 bytes at a time in one shot, Java will be transferring 8192 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read or write 2048 bytes at a time in one shot, Java will be transferring 8192 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read 128 bytes at a time in one shot, Java will be transferring 8192 bytes in each (expensive) interaction it has with the Operating System and hardware.

If you read and write single characters, Java will be transferring 8192 bytes in each (expensive) interaction it has with the Operating System and hardware.

So 8192 bytes of data written always means exactly one (expensive) interaction between Java and the Operating System and hardware.

I mentioned flushes for when you are in a rushes (decrease latency by sacrificing thru-put).  Why are flushes even a thing if you aren't using BufferedReader/BufferedWriter etc.?

From the javadocs:

Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination.
If the intended destination of this stream is an abstraction provided by the underlying operating system, for example a file, then flushing the stream guarantees only that bytes previously written to the stream are passed to the operating system for writing; it does not guarantee that they are actually written to a physical device such as a disk drive.



So remember, the BufferedReader/BufferedWriter or BufferedOutputStream, etc. is wrapping some code we couldn't look at because it wasn't Java, but native code provided with the JDK?

Flush can be telling that native code we can't look at to make sure it isn't holding anything back or leaving anything waiting for it.
This is good if someone just can't wait for that time critical data until some big fat buffer fills up.
But for thru-put over the long haul, it is way more efficient to do things with an appropriate buffer size.

For true optimization, you would need to base the buffer size on things you can't know in advance.  Hardware, OS, various settings, which file system you are reading or writing from...

The book makes clear tho that ANY buffered stuff will be way, way, way faster for the reasons I stated above.

Just ask to read the whole file in one shot and be done with it?  If you know it is small enough for that to work well, fine.
But Java is commonly enough used for enormous data sizes where that approach is just nuts.

Reading 896 GB of 80 character lines for an application that only actually needs to see one line at a time, for instance, is just nuts.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:Is there an objective experiment that could be performed to tell the difference??


In the foregoing quote, you speak of a "difference." However, this information you provide (which speaks of some "difference") seems to be already subsumed in the following information you provided earlier in this discussion thread:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.


Kindly refer to the code example I provided in the first post I made, which started this discussion thread. If the array size on line 7 is changed from, for example, 100 to 8192 then the long description you provided alludes that the following will happen (please, correct me if I have gotten you wrong anywhere):

(1.) The read operations that happen on lines 13 and 22 will attempt to read 8192 characters at a time (i.e., this much data will be attempted to be read, whether the non-buffered or buffered classes are used).

(2.) The write operations that happen on lines 15 and 24 will attempt to write as many characters, at a time, as the integer value stored/held in the char_length identifier (i.e., this much data will be written, whether the non-buffered or buffered classes are used).

The discussion in the study guide advises that an effort needs to be exerted, in order to determine an optimal buffer size. However, this effort to determine an optimal buffer size would need to be exerted whether some code implementation uses the non-buffered classes or it uses the buffered classes. Does your long description seek to demonstrate that this is not the case? If your long description seeks to demonstrate this then I still can't see how it has done so.

In summary, and in other words, your new information, about some "difference" between the behavior of the buffered and non-buffered classes, seems to already be captured by the old remark you made; however, of course, correct me if I am wrong about this).
 
Jesse Silverman
Ranch Foreman
Posts: 627
13
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
As both the book and earlier replies in this thread have stated, there is generally a huge difference between buffered and non-buffered IO performance, quite dramatic.

If enough is known about the hardware, drivers, OS and other environment and the data to be encountered, even further optimization can be obtained by tuning even farther for buffer size.
That level of optimization may not be portable across environments.

The idea that once one figures out an optimum buffer size, the work is done, and thus the Buffered* classes are unnecessary, because then one will only read or write that size of data at a time, is indeed deciding to take on the responsibility of buffering oneself, as I described earlier in the thread.

The buffered streams and readers and writers allow one to write code in a style natural to the logic of the problem space, rather than focusing the logic flow on a buffer size which is purely an artifact of the solution space, and not even a portable one at that.

I came from a lifetime of having to "do everything myself" (not in Java!!)
Having tried it more than enough, I don't wish to go back to that lifestyle.

The ratio of effort to results is just too high.
 
Paul Clapham
Marshal
Posts: 26697
81
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:The idea that once one figures out an optimum buffer size, the work is done, and thus the Buffered* classes are unnecessary, because then one will only read or write that size of data at a time, is indeed deciding to take on the responsibility of buffering oneself, as I described earlier in the thread.



It isn't even necessary to figure out an optimum buffer size. A reasonable guess is already enough, as is using the default buffer size which is built into BufferedReader. And yeah, one of the great things about Java is that you don't need to spend your time reinventing wheels. Not only is BufferedReader better than what you or I would write because it already exists and it requires zero time to choose it, it has been around for a long time and all of the tricky edge cases that you or I might miss when we reinvented it, those are all taken care of.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Jesse Silverman wrote:As both the book and earlier replies in this thread have stated, there is generally a huge difference between buffered and non-buffered IO performance, quite dramatic.


The "huge difference between buffered and non-buffered IO performance," of which you speak in the foregoing quote, seems to me to be considered moot (i.e., under the right condition), by even you yourself, in the following quoted remark you made:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.


Jesse Silverman wrote:The idea that once one figures out an optimum buffer size, the work is done, and thus the Buffered* classes are unnecessary, because then one will only read or write that size of data at a time, is indeed deciding to take on the responsibility of buffering oneself, as I described earlier in the thread.


Like I already mentioned earlier, there is zero extra effort taken, in the example code I provided, to implement the code using the non-buffered classes, instead of using the buffered classes; in other words, setting the array size on line 7 of this code, to the ostensible default buffer size when the buffered classes are used, is indeed zero effort.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Paul Clapham wrote:And yeah, one of the great things about Java is that you don't need to spend your time reinventing wheels.


I can't say that I disagree with you that reinventing wheels is a wasteful effort. However, I am yet to see how setting the array size on line 7 of the code I provided, to the ostensible default buffer size when the buffered classes are used, is any more than truly zero effort. With this effort having a magnitude of zero, this fact is hardly tantamount to an effort exerted in reinventing an already invented wheel.

Paul Clapham wrote:Not only is BufferedReader better than what you or I would write because it already exists and it requires zero time to choose it, it has been around for a long time and all of the tricky edge cases that you or I might miss when we reinvented it, those are all taken care of.


I would be happy to learn of all the ways in which, as you put it, "BufferedReader [is] better than what you or I would write." In all our deliberations and discussion in this discussion thread, I am yet to be provided information that explains and illustrates this claim. Don't get me wrong, I am not disputing that this claim is accurate; rather, I am simply saying that the claim is yet to be adequately explained to me.
 
Saloon Keeper
Posts: 13072
281
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
The original code is just a demonstration of how using a buffered stream can increase throughput when compared to a bare file stream.

Yes, you can change the amount of bytes read from the stream to coincide with the size of the buffer used internally by the buffered stream, and it will effectively make the buffered stream pointless, but such a scenario is not probable in the real world.

In the real world, you typically only want to work with a handful of bytes at a time, not thousands. Requesting only a handful of bytes at a time from a file without buffering input is extremely slow.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Stephan van Hulst wrote:The original code is just a demonstration of how using a buffered stream can increase throughput when compared to a bare file stream.


Stephan van Hulst wrote:Yes, you can change the amount of bytes read from the stream to coincide with the size of the buffer used internally by the buffered stream, and it will effectively make the buffered stream pointless, but such a scenario is not probable in the real world.


In the foregoing quotes of remarks you made, you are simply having a debate with yourself and, unfortunately, this debate does not assist me in any way.

Stephan van Hulst wrote:In the real world, you typically only want to work with a handful of bytes at a time, not thousands. Requesting only a handful of bytes at a time from a file without buffering input is extremely slow.


Unfortunately, this remark you have made does not provide adequate information to educate me, regarding my inquiry in this discussion thread.
 
Stephan van Hulst
Saloon Keeper
Posts: 13072
281
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Your inquiry seems to be: "what benefit does BufferedInputStream provide when I pass an array to the read() method that has a size similar to the buffer size used by the BufferedInputStream internally?"

Multiple contributors have pointed out that in such a case, there is no benefit.

I added that such a case is purely academic. In practice, you would virtually never pass an array of such a large size to the read() method, because there is no good use case for it.
 
Paul Clapham
Marshal
Posts: 26697
81
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Nyeng Gyang wrote:

Paul Clapham wrote:Not only is BufferedReader better than what you or I would write because it already exists and it requires zero time to choose it, it has been around for a long time and all of the tricky edge cases that you or I might miss when we reinvented it, those are all taken care of.


I would be happy to learn of all the ways in which, as you put it, "BufferedReader [is] better than what you or I would write." In all our deliberations and discussion in this discussion thread, I am yet to be provided information that explains and illustrates this claim. Don't get me wrong, I am not disputing that this claim is accurate; rather, I am simply saying that the claim is yet to be adequately explained to me.



Yes... you do seem to have trouble understanding explanations, don't you? Not only that, you do seem to require explanations for almost everything. It seems hardly worthwhile trying to provide explanations since you aren't going to understand them anyway.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Stephan van Hulst wrote:I added that such a case is purely academic. In practice, you would virtually never pass an array of such a large size to the read() method, because there is no good use case for it.


This additional information you provided is moot to my inquiry. It is enough for me to know that the advantage, which you describe exists only in a purely academic case and not in practice, is not an advantage (under the right condition) of using the buffered classes over the non-buffered classes. So long as you, or any other contributor to this discussion thread, continues to present this "advantage" as an advantage of using the buffered classes over the non-buffered classes, I will continue to remark that I don't see this alleged advantage of using the buffered classes over the non-buffered classes.
 
Nyeng Gyang
Ranch Hand
Posts: 100
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Paul Clapham wrote:Yes... you do seem to have trouble understanding explanations, don't you?


I have had no prblems understanding the following explanations:

Jesse Silverman wrote:I don't think I see additional benefits from using BufferedFileWriter over FileWriter if all writes are always done in sizes >= the buffer size anyway.

Stephan van Hulst wrote:Multiple contributors have pointed out that in such a case, there is no benefit.


The only explanation that I am having a hard time understanding is an explanation that is presented as though it is different than the information furnished in the above two quotes.

Paul Clapham wrote:Not only that, you do seem to require explanations for almost everything. It seems hardly worthwhile trying to provide explanations since you aren't going to understand them anyway.


I will continue to request for as much explanation as I require and readers of such requests I make will continue to be at liberty to either entertain these requests and provide me the requested information or disregard/ignore the requests and decline to provide me the information.
 
Jeanne Boyarsky
author & internet detective
Posts: 40677
827
Eclipse IDE VI Editor Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator

Nyeng Gyang wrote:I will continue to request for as much explanation as I require and readers of such requests I make will continue to be at liberty to either entertain these requests and provide me the requested information or disregard/ignore the requests and decline to provide me the information.


I think this topic has been discussed at length. More importantly, we are in a cert forum. If you get a question on the exam about the benefit of buffered streams, it is performance. You need to answer exam questions based on commonly accepted wisdom, whether you see that in practice or not.

Note: This thread is starting to sound more about whether to have a discussion and less about buffered readers. I'm locking it. For the exam, the answer is "buffered is more performant". if you want to discuss performance itself and have a real world use case where it matters, we have a separate performance forum for that.
 
I hired a bunch of ninjas. The fridge is empty, but I can't find them to tell them the mission.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic