[Off-Topic] John Carmack's point of view on GC and languages like JavaScript

[H. S. Teoh]

On Mon, Aug 08, 2022 at 07:11:46PM +0000, Don Allen via Digitalmars-d wrote:
> On Sunday, 7 August 2022 at 22:39:24 UTC, Paulo Pinto wrote:
[...]
> > Discord switched to Rust, because they wanted to work in cool new
> > toys, that was the actual reason, while they use Electron for their
> > "desktop" app.
> > 
> > Meanwhile companies ship production quality firmware for IoT secure
> > keys written in Go.
> 
> I think this kind of
> start-with-the-desired-conclusion-and-work-backwards thinking seems to
> be alarmingly prevalent in the computing world (and on the Supreme
> Court). It is certainly a requirement for being a Rust fan-boy.
> 
> But I can tell you that I saw this kind of thing 50+ years ago (human
> nature just doesn't change), when performance measurement was my
> specialty. I constantly ran into people who "just knew" why certain
> code, even their code, performed as it did. Measurements (evidence)
> were/was unnecessary. I could tell you many war stories where these
> people were dead wrong (almost always), even about the behavior of
> their own code.

Once upon a time, I was one of those guilty as charged. I cherished my
l33t C skillz, hand-tweaked every line of code in fits of premature
optimization, and "just knew" my code would be faster if I wrote `x++`
instead of `x = x + 1`, ad nauseaum.

Then one day, I ran a profiler.

It revealed the performance bottleneck was somewhere *completely*
different from where I thought it was. (It was a stray debug printf that
I'd forgotten to remove after fixing a bug.)  Deleting that one line of
code boosted my performance MAGNITUDES more than countless hours of
sweating over every line of code to "squeeze all the juice out of the
machine".

That was only the beginning; the first dawning of the gradual
realization that I was actually WRONG about the performance of my code.
Most of the time.  Although one can make educated guesses about where
the bottleneck is, without hard proof from a profiler you're just
groping in the dark. And most of the time you're wrong.

Eventually, I learned (the hard way) that most real-world bottlenecks
are (1) not where you expect them to be, and (2) can be largely
alleviated with a small code change. Straining through every line of
code is 99.9% of the time unnecessary (and an unproductive use of time).
Always profile, profile, profile.  Only optimize what the profiler
reveals, don't bother with the rest.

That's why these days, I don't pay much attention to people complaining
about how this or that is "too inefficient" or "too slow".  Show me
actual profiler measurements, and I might pay more attention. Otherwise,
I just consign it to the premature optimization bin.


T

-- 
In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.