We are forking D

[H. S. Teoh]

On Mon, Jan 08, 2024 at 02:58:58AM +0000, Don Allen via Digitalmars-d wrote:
[...]
> The speed of the code generated by the language you are using is not
> necessarily the determining factor of the speed of your application.
> If your application is not cpu-limited and written in Python,
> re-writing it in C++ in pursuit of better performance is going to be a
> disappointment. If your application *is* cpu-limited but spends most
> of its time in some library, e.g.,sqlite, or in system-calls,
> re-writing it in C++ will only help in proportion to the time spent in
> your own code, which is small by assumption.

I learned this the hard way over the years.  I used to be a
self-proclaimed C/C++ expert, took pride in knowing obscure corners of C
that very few others knew (I managed to answer correctly an obscure
interview question that even the interviewer didn't know the answer to).
I thought I knew it all about optimization, and that I could optimize
just by looking at the code.

Boy was I wrong.

This one time I was having performance issues with my code, and I spent
hours poring over every single line and optimizing it to next year and
back.  The overall performance improvement was a disappointment.
Finally, I conceded to using a profiler (before that I felt profilers
were for wimps who didn't know how to program properly). The profiler
instantly found the problem: a stray debug printf() that I forgot to
remove after fixing a bug, that just happened to be sitting in the hot
path.

That was just one of many, many such instances of hard reality smacking
me upside the head.  After many years of such experiences, I began to
realize just how wrong I am 90% of the time when it comes to
performance.  The bottleneck is usually far away from where I assumed
it'd be.  After learning this the hard way time and again, I learned one
thing:

	Until you run a profiler on your program, you are most probably
	wrong about where the bottleneck is.

The corollary goes:

	If you're optimizing a piece of code before running a profiler
	on it, it's premature optimization and you're probably wasting
	your time.

The general theorem reads:

	Discussions about performance without hard numbers produced by
	actual profiler output are usually wrong.  Until you profile,
	it's all just guesswork and unfounded assumptions.

The practical takeaway is, whenever performance is an issue:

	Profile, profile, profile.

If you're not profiling and you talk about performance, I probably won't
bother reading any further.  Or perhaps I would, but more for the
entertainment value than any true technical merit.


> My point is that the performance vs. ease-of-coding tradeoff is not
> simple.  It takes some smart engineering for a project to be near the
> sweet spot.
[...]

Yep, optimization is an extremely complex problem that's very sensitive
to fine details, and often, the exact use case or even exact data you're
operating on.  Sweeping general statements about performance are rarely
accurate, and not worth relying on unless there's hard data to back it
up. And that's profiler data, not some made-up numbers made from some
preconceived notion about optimization that's not based in reality.


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N