Slow performance compared to C++, ideas?

[Joseph Rushton Wakeling]

On 05/31/2013 05:12 PM, bearophile wrote:
> There are many kinds of D code, not everything is a high performance ray-tracer
> or 3D game. So I'm sure there are many many situations where using the C++ STL
> is more than enough. As most tools, you need to know where and when to use them.
> So it's not a Satan-spawn :-)

It's the Microsoft Office of programming solutions -- people get taught that
this is the tool to use and don't get adequately taught about the alternatives
or the rationale ...

I well remember my first experience with STL as a new postgraduate, _very_
inexperienced at programming (what's changed? :-P ) and having learned basically
a small part of C.  I was writing some code where I needed at each time step to
collect a list of indices of array entries whose value would change.

The only way I could think of how to do this in C was to use malloc to create an
array of length N, and to store the actual number of indices stored at a given
time step as a size_t which got reset to zero at the start of each step.  So, I
could store as many indices as there were to list; the malloc was done at the
start of the whole process, outside the loop of time steps.

Then I talked with a (much more experienced) colleague about the design of my
code and this thing I was doing with a set of data that started from empty every
time and built up the list of indices, and he said, "Oh, try using the vector
type in C++."

So, I went, and discovered a bit about how it worked, and rewrote all my code
using vectors in place of arrays and other nice C++ stuff, and I managed to come
up with code that was much, much easier to read, and was ten zillion times
slower.  (I can't remember now, but I suspect that my use of vector was carrying
out lots of unnecessary allocs and frees within the core loop.)

I'd surely do much better these days (e.g. I'd make sure to define the vector
outside the loop and to reserve the exact amount of memory required up front),
but it was a nice lesson in how clever, generic-looking tools can be a big
problem if you don't understand how to use them.