3 ms·

As I see it, performance only matters if you're losing more customers or users over it than you gain by having spent that effort on features. And hardware is ch

As I see it, performance only matters if you're losing more customers or users over it than you gain by having spent that effort on features. And hardware is cheap nowadays. This is also not a linear relationship, performance focused development generally constrains the system which makes refactoring harder which makes new features harder (because you almost certainly did not get the architecture right the first time around).

jaclaz 7y ago
>And hardware is cheap nowadays. Cheap and available (and correctly setup) are not synonyms, however. In the years I observed how - generally speaking - programmers (correctly as it is their work) tend to have the best of the best in hardware (and a fast LAN, and a fast WAN, etc.) so locally where the program is developed it feels fast, responsive, etc. But the user base may have older processors, less RAM, slower mass storage and slower WAN/Internet access, so at their end the same program will appear slow, in some cases so slow to make it unusable. I always thought that at the developers there should exist a few reasonably old machines possibly with installed the same services/other tools that the client target machines normally have where the program should be tested for excessive increased slowness compared to what happens on the development machines.
- mratsim 7y ago
  Thankfully, Travis, Azure Pipelines and Appveyor are slow as molasses and if you are forced to wait for them before merging a commit you will optimize the speed so that at least CI is reasonably fast.
daxfohl 7y ago
I agree with most of what you said, except hardware isn't really all that cheap. I used to think so, but recently have run up against some "that's all this box can do?" and "this throughput costs this much?" and "why is this so slow" with fairly good algorithms but a lot of data and rps. So I've been a tad more perf forward lately than in the past.

jaclaz 7y ago

>And hardware is cheap nowadays. Cheap and available (and correctly setup) are not synonyms, however. In the years I observed how - generally speaking - programmers (correctly as it is their work) tend to have the best of the best in hardware (and a fast LAN, and a fast WAN, etc.) so locally where the program is developed it feels fast, responsive, etc. But the user base may have older processors, less RAM, slower mass storage and slower WAN/Internet access, so at their end the same program will appear slow, in some cases so slow to make it unusable. I always thought that at the developers there should exist a few reasonably old machines possibly with installed the same services/other tools that the client target machines normally have where the program should be tested for excessive increased slowness compared to what happens on the development machines.

mratsim 7y ago
Thankfully, Travis, Azure Pipelines and Appveyor are slow as molasses and if you are forced to wait for them before merging a commit you will optimize the speed so that at least CI is reasonably fast.

daxfohl 7y ago

I agree with most of what you said, except hardware isn't really all that cheap. I used to think so, but recently have run up against some "that's all this box can do?" and "this throughput costs this much?" and "why is this so slow" with fairly good algorithms but a lot of data and rps. So I've been a tad more perf forward lately than in the past.