Fantastic exchange from DConf

[H. S. Teoh via Digitalmars-d]

On Wed, May 10, 2017 at 11:16:57AM +0000, Atila Neves via Digitalmars-d wrote:
[...]
> The likelihood of a randomly picked C/C++ programmer not even knowing
> what a profiler is, much less having used one, is extremely high in my
> experience.  I worked with a lot of embedded C programmers with
> several years of experience who knew nothing but embedded C. We're
> talking dozens of people here. Not one of them had ever used a
> profiler. In fact, a senior developer (now tech lead) doubted I could
> make our build system any faster. I did by 2 orders of magnitude.

Very nice!  Reminds me of an incident many years ago where I "optimized"
a shell script that took >2 days to generate a report by rewriting it
Perl, which produced the report in 2 mins. (Don't ask why somebody
thought it was a good idea to write a report generation script as a
*shell script*, of all things. You really do not want to know.)


> When I presented the result to him he said in disbelief: "But, how? I
> mean, if it's doing exactly the same thing, how can it be faster?".
> Big O?  Profiler? What are those? I actually stood there for a few
> seconds with my mouth open because I didn't know what to say back to
> him.

Glad to hear I'm not the only one faced with senior programmers who show
surprising ignorance in matters you'd think they really ought to know
like the back of their hand.


> These people are also likely to raise concerns about performance
> during code review despite having no idea what a cache line is. They
> still opine that one shouldn't add another function call for
> readability because that'll hurt performance. No need to measure
> anything, we all know calling functions is bad, even when they're in
> the same file and the callee is `static`.

Yep, typical C coder premature optimization syndrome.

I would not be surprised if today there's still a significant number of
C coders who believe that writing "i++;" is faster than writing
"i=i+1;".  Ironically, these same people would also come up with
harebrained schemes of avoiding something they are prejudiced against,
like C++ standard library string types, while ignoring the cost of
needing to constantly call O(n) algorithms for string processing
(strlen, strncpy, etc.).

I remember many years ago when I was still young and naïve, in one of
projects, I spent days micro-optimizing my code to eliminate every last
CPU cycle I could from my linked-list type, only to discover to my
chagrin that the bottleneck was nowhere near it -- it was caused by a
debugging fprintf() that I had forgotten to take out.  And I had only
found this out because I finally conceded to run a profiler.  That was
when this amazing concept finally dawned on me that I could possibly be
*wrong* about my ideas of performant code, imagine that!

(Of course, then later on I discovered that my meticulously optimized
linked list was ultimately worthless, because it has O(n) complexity,
whereas had I just used a library type instead, I could've had O(log n)
complexity.  But I had dismissed the library type because it was
obviously "too complex" to possibly be performant enough for my
oh-so-performance-critical code. (Ahem.  It was a *game*, and not even a
good one. But it absolutely needed every last drop of juice I could
squeeze from the CPU.  Oh yes.))


> I think a lot of us underestimate just how bad the "average" developer
> is. A lot of them write C code, which is like giving chainsaws to
> chimpanzees.
[...]

Hmm. What would giving them D be equivalent to, then? :-D


T

-- 
If you're not part of the solution, you're part of the precipitate.