
Does software performance still matter? - joebaf
http://lemire.me/blog/2017/03/20/does-software-performance-still-matter/
======
oldmancoyote
No one answer works for everyone nor for every situation.

I've been programming for 49 years. I'm self-taught and not very good at it,
but people thought I was brilliant. They did because I ignored efficiency and
pushed the machine far beyond what was done by those folks who were
handicapped by their concern for efficiency.

One program ran for 3 days. Another user-focused highly interactive program
kept the user waiting for 26 minutes. It didn't matter how long it took
because the result blew everyone away. It looked like something out of Star-
trek even though it was straight forward work. I felt guilty because I knew
there were far better programmers working there, but they were unwilling to
abandon small foot print and rapid execution as the metrics of "good"
programming.

This worked for me because I could choose my own projects within the limits of
my employer's goals. Creativity mattered. Again, there is no one answer to
this question. It depends of the situation.

~~~
oldmancoyote
I haven't worked professionally since 1995, so my example will seems too
obvious. It's hard to believe how drastically things have changed and how our
_expectations_ have changed.

My most striking work was finished in 1989. Any mildly competent programmer
could use a framework to do what I did today. I had to carve my own framework
out of a block of wood. Maybe I exaggerate a little bit. Yet, creating that
framework wasn't really difficult. The technology (dynamic color graphics and
mouse monitoring) had been around for a few years.

We had a data base of polygons representing the boundaries of geological
formations, a data base of mineral deposits, and an extensible data base
program (4D). I wrote extensions to display interactive geologic maps on a mac
screen.

The user did a search for mineral deposits of interest. The mac displayed
their locations on a custom map. When the user clicked on a location, the mac
displayed the complete data record for the deposit. The user could get similar
information for other objects displayed, e.g. faults, Forest Service
boundaries... Believe it or not the USGS national headquarters was actually
considering waking up Ronald Regan to show him what we could do. Times have
changed.

Most GUI apps at that time were pretty static. Click on a button. Type into a
text field. Click on a text link. Drag a rectangle... Complex displays that
were custom created for the user and that contained deep information were
largely unknown.

"Programmers did not do things like that." While I had great respect for those
guys, they were self-limited by their expectations. The very real demands for
small footprints and fast execution times imposed by hardware and software
limitations of the past few decades had been so binding on the profession's
expectations that few of us realized we were unnecessarily limiting our
imaginations. Times had changed. The first time this app ran, it took 26
minutes. It did not matter. That's what the others missed. Any passing similar
inspirations (and I'm sure many had them) were immediately rejected as
unrealistically slow, too futuristic to consider practical.

I think that our expectations are still limited by excessive concern for
efficiency. I admit that programmers working in a production environment have
little or no choice in the matter. There, creativity is properly focused on
obtaining efficiency.

The big question is what marvelous innovations are our current perspectives
grounded in the past hiding from us, innovations that in the future will be
considered mundane.

------
YCode
We've all heard this, but it's important to practice it:

Premature optimization is the root of all evil.

~~~
tropo
Too often the word "premature" is forgotten, and too often "optimization" is
understood to be "any care about performance whatsoever, either low-level or
high-level".

The comment comes from a time when people would regularly do foul things like
changing code similar to a switch/case into something that involves shoving an
integer directly into a flags register or worse. (then you must add another
case or port to different hardware... uh oh!)

Failure to think about performance from the beginning can get you in deep
trouble. The worst case is when there is no bottleneck to be found by a
profiler; instead there is slowness spread all throughout. This may force a
total rewrite or abandonment of the project. Language choice is particularly
prone to causing this, but habitual poor choices can mess you up just as
badly.

------
na85
Based on my web browsing experience these last few years, fewer and fewer
JavaScript devs feel that performance matters.

