[...]
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.
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;
I think the arguments in favor of a long running server are
stronger than those against it in the case of compilers.
The design and implementation have to be such that separate
requests do not interfere with each other. There are some
steps that you can take that help in that area, but don't
require anything like a new process and a completely fresh
start. Besides the basic efficiencies afforded, there's
a lot of basic information that doesn't change between
requests. Why rescan/prepare for <vector> billions of
times when it doesn't change one little bit? It surprises
me that you question this given what I know of your
background.
you don't want
start up time to be too long there, either.
It has to done efficiently. Single-run compilers are a
luxury that is fading. I harp on this, but gcc needs to
be overhauled twice. First a rewrite in C++ and then a
rewrite to be an on line compiler. The first phase of
the on line part could be to simply run once and exit
after each request. That though would have to be
replaced by a real server approach that runs like a
champ. They are so far away from this it isn't even
funny. As far as I know all they are working on is
C++0X support. Some of that is important, too, but
they shouldn't keep ignoring these other matters.
It may be that gcc has just become a dinosaur that
can't adapt to the times. They certainly haven't
done a good job keeping up in some respects. Where's
the "gcc on line" page like some compilers have? And
even the compilers that have that type of page
haven't done much with them in the past ten years.
I understood this stuff in 1999 so don't think it
should be a surprise to people now. The internet is
here to stay. I didn't vote for George W. Bust (I lived
in Texas when he was governor and I voted for him as
governor at least once, but by the time he ran for
President I was on to him. I didn't vote for Barack
Obama, aka B.O., either.), but one thing Bust got right
was to encourage people to bring new services on line in
many of his speeches. The US would be busted even worse
if not for that consistent encouragement.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
"Trust in the L-rd with all your heart and lean not on
your own understanding. In all your ways acknowledge
him and he will direct your paths." Proverbs 3:5,6