3 ms·

I've made this comment before on here. I purposely develop on older hardware because of performance concerns. Pretty much any code you write performs well on

by 51Cards 15y ago

I've made this comment before on here. I purposely develop on older hardware because of performance concerns. Pretty much any code you write performs well on an i7 but will it perform well when it gets to your clients who are all stuck running Celerons? I always keep my development machines back a few levels so that I know if it runs well for me, it will for the end user.

martianpenguin 15y ago
ideally, you should have an entire test environment with every level of hardware that your product could run on... that should be entirely separate from your dev/coding machine. That should be much easier to justify to management too.
dangravell 15y ago
That's often my thought too. Surely we can have the best of both worlds though? How far has virtualisation come in _simulating_ slower machines, whether it be cpu, network, memory or storage constraints?
- aidenn0 15y ago
  Not good enough. Caches are the killer. A coworker of mine committed code that ran fine on his machine, but was rejected by our nightly tests on older machines. It turns out it wasn't that long ago that sub 1MB caches were standard, but his machine has 8MB of cache. This meant about a 20x reduction in performance on this algorithm (though some of that was also ALU performance).
Havoc 15y ago
Surely the best way to do it is to develop on the best machine available but then occasionally test it on inferior hardware just to make sure you're still on track? Intentionally crippling the entire dev environment seems a bit drastic to me.
- 51Cards 15y ago
  I don't see it as crippling at all... I don't develop on a 486 :) But you also don't need to sit on an i7 either which was the thought in the article. If your target audience is using typical hardware then most of the time you can easily use typical + 1 to develop. Then you can spot issues as they arise and not later when you kick to the test environment. The more you can catch in-process is less you have to re-architect later. Of course every situation will vary. Just my thoughts anyhow.
  - mahyarm 15y ago
    That doesn't really work when you have a complex system that spans servers, clients, databases, custom libaries,etc. And a large large test suite.

by 51Cards 15y ago

martianpenguin 15y ago

ideally, you should have an entire test environment with every level of hardware that your product could run on... that should be entirely separate from your dev/coding machine. That should be much easier to justify to management too.

dangravell 15y ago

That's often my thought too. Surely we can have the best of both worlds though? How far has virtualisation come in _simulating_ slower machines, whether it be cpu, network, memory or storage constraints?

aidenn0 15y ago
Not good enough. Caches are the killer. A coworker of mine committed code that ran fine on his machine, but was rejected by our nightly tests on older machines. It turns out it wasn't that long ago that sub 1MB caches were standard, but his machine has 8MB of cache. This meant about a 20x reduction in performance on this algorithm (though some of that was also ALU performance).

Havoc 15y ago

Surely the best way to do it is to develop on the best machine available but then occasionally test it on inferior hardware just to make sure you're still on track? Intentionally crippling the entire dev environment seems a bit drastic to me.

51Cards 15y ago
I don't see it as crippling at all... I don't develop on a 486 :) But you also don't need to sit on an i7 either which was the thought in the article. If your target audience is using typical hardware then most of the time you can easily use typical + 1 to develop. Then you can spot issues as they arise and not later when you kick to the test environment. The more you can catch in-process is less you have to re-architect later. Of course every situation will vary. Just my thoughts anyhow.
- mahyarm 15y ago
  That doesn't really work when you have a complex system that spans servers, clients, databases, custom libaries,etc. And a large large test suite.