stdio performance in tango, stdlib, and perl

[James Dennett]

Walter Bright wrote:
> James Dennett wrote:
>> I'm at a loss to understand why you would write what you
>> did.  It seems to be a straw man, but maybe there was
>> something else to it -- frustration that people assume
>> that D must be slower than C++?
> 
> Maybe it is a bit of frustration on my part. I often run into people
> who, when faced with benchmarks showing that conventional D runs code
> faster than conventional C++, tell me in various ways that it can't be
> true. I must have:
> 
> 1) written bad C++ code
> 2) lied
> 3) used a sabotaged C++ compiler
> 4) written some magic optimization that only works on that carefully
> crafted benchmark
> 
> So, I have some justification in saying what I did about the
> conventional wisdom of C++. I also know that the top tier of experienced
> C++ programmers are well aware such conventional wisdom is not true.
> 
> I have a lot of experience in making C++ code run fast. It doesn't come
> easy, it takes a lot of work back and forth with a profiler. It usually
> involves going around the C++ runtime library. That experience has
> certainly strongly influenced the design of D. I don't wish to have to
> write custom I/O just to get good I/O performance. I don't wish to keep
> doing all the clever string hacks trying to make 0 terminated strings fast.
> 
> I want the natural, straightforward D code to be (at least close to) the
> best performing way to implement an algorithm.

Good answer.  (Yes, seriously.)

It's certainly true that for code doing large amounts of
I/O where performance was an issue, I've always avoided
IOStreams in these situations; no implementation I've used
has been anywhere near fast enough.  IOStreams is also a
pain where robustness is required.  It's most useful for
simple tools that are used in tame environments.

The last time I had to get out a profiler to optimize
C++ code, it turned out to mostly be an exercise in
avoiding (a) a terribly inefficient implementation of
std::string, and (b) a mind-bogglingly inefficient
implementation of strftime.  Which I guess illustrates
how important it is that the out-of-the-box, natural
ways to write code should have performance that is not
too far removed from optimal.

It might be harsh, but not entirely unjustified, to say
that the "conventional wisdom" of many communities of
programmers is a long, long way from being wise.  As
the community behind a language grows larger, there is
a natural tendency for it not to have some a density
of experts; if D amasses a million users it's a safe
bet than most of them won't be as sharp as the average
D user is today.

-- James