4 ms·

Does software performance still matter?

11 points by joebaf 10y ago

oldmancoyote 10y ago
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.
- thekingofh 10y ago
  Do you mind expanding on some examples? I find this highly interesting.
- oldmancoyote 10y ago
  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.
na85 10y ago
Based on my web browsing experience these last few years, fewer and fewer JavaScript devs feel that performance matters.
YCode 10y ago
We've all heard this, but it's important to practice it: Premature optimization is the root of all evil.
- tropo 10y ago
  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.

11 points by joebaf 10y ago

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.

thekingofh 10y ago
Do you mind expanding on some examples? I find this highly interesting.
oldmancoyote 10y ago
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.

na85 10y ago

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

YCode 10y ago

We've all heard this, but it's important to practice it: Premature optimization is the root of all evil.

tropo 10y ago
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.