On Thu, 3 Sep 2015 05:37:14 -0700 (PDT) WALID BELRHALMIA wrote:
@jesse you wont to tell me that when we call read function on a
Bufio.Reader we put the byte from the file into the buffer , and when
all the buffer size is plenty we read from the buffer into the p
Calm down and try to absorb the idea that buffering works (almost)
The whole point of buffering is to provide faster access to a resource
which has high cost of being accessed in terms of performance.
Say, you need to read a file on the file system one byte at a time.
If you weren't using buffering, reading each byte would actually reach
for the kernel asking it to reach for the file system layer and so on.
Now you add buffering. Then reading the first byte in the sequence
will -- transparently for you -- ask the kernel for more data, say,
4096 bytes; these bytes will be saved into the buffer, and the read
operation will return the first byte -- just what you asked for.
But the difference becomes obvious when you try reading the next byte:
it will be served right from the buffer, and this means no kernel is
involved at all -- the access will be super fast. When the buffer is
drained, an attempt to read the data past what's buffered will trigger
real access to the kernel, its filesystem layer and so on, but again
more data than you've requested will be asked for, acquired and
buffered, and the process repeats.
What this means for you, is that you almost never want to know how many
bytes are not yet read among those buffered. Right now I even fail to
fancy what that would be really useful for, to be honest.
So possibly you just should stop worrying about these details and just
use buffering to read data in chunks of whatever size is convenient for
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.