Re: Question about reading from stream.
On Mar 26, 8:44 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
[...]
Those are good suggestions, and we all can agree that to
optimize one most often needs to measure first. But it
does not take a measurement to know that IO is a
bottleneck. In every application. Hardware is
I partially disagree.
With what, exactly?
> IO is always slow, that's true.
That's it. Period. Slow. When you read data from a file or
write data to a file, IO is the bottleneck, not conversions
(if any), not compression (if any), not creation of any other
auxiliary objects...
That's usually true, but not always. I've seen cases where
compression was a "bottleneck" (although this is relative---in
the final code, more time was spent on compression than on the
physical writes, but the program was still faster with the
compression, since it wrote a lot less). And I've seen cases
where where allocations were far more significant than the
actual writes. So there are exceptions.
And of course, if you're writing to a pipe under Unix, the
writes can be very, very fast.
But for many applications the time spent doing and waiting
for IO is not the majority of their run time.
No, but what does their overall run time have to do with the
fact that during reading or writing data the interaction with
the device through the platform abstractions (isn't that what
the streams are?) is the slowest part?
Well, if you eliminate the other causes, IO will end up being
the slowest remaining part.
Why do customers care about startup time or the time it takes
to load a file into the application? They only do it a few
times a day.
That depends on the application. I've written servers that run
for years at a time---startup time isn't significant. But I've
also written a lot of Unix filters, which are invoked
interactively (often on a block of text in the editor). In such
cases, start-up time can be an issue. (If you doubt it, try
using one written in Java---where loading the classes ensures a
significantly long start up time.)
And if the application is stable, you don't have to shut it
down at all, ever, right?
It depends on the application. What if it's a compiler? Or a
Unix filter like grep or sed? For that matter, if clients share
no data directly, there are strong arguments for starting up a
new instance of a server for each connection; you don't want
start up time to be too long there, either. (Note that on the
server I currently work on, the start-up time is several tens of
seconds---the time to reconstruct all of the persistent data
structures in memory, resynchronize with the data base, etc.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34