Developing When Your Computer is too Fast
dustin.github.com
Developing When Your Computer is too Fast
1–10 of 32 posts
Re: Developing When Your Computer is too Fast
#2Great work, but I think a library to do the opposite would be more useful.
Re: Developing When Your Computer is too Fast
#3I actually have a dev box that's an older Athlon XP with 1 GB of RAM that is surprisingly useful for finding performance issues. Things that don't show up on my monster desktop show up -really- fast on the clunker.
I'm a firm believer that developers should have old hardware to test on. :)
Re: Developing When Your Computer is too Fast
#4Fun, but the good thing about slow computers is that they're also the cheapest; it's far more economical to just buy an old box for a couple hundred dollars (or even cheaper).
Re: Developing When Your Computer is too Fast
#5I have been programming since the late 80's and one thing I learned early was to always develop (or at least extensively test) on older hardware. My primary work machine is usually a generation or two old. At present I code on a T42 Thinkpad and there is a new T60 waiting to take over in a couple months. If you're forced to develop in a "slow" environment you learn to optimize your code from the get go, all the time. You automatically rely on faster techniques as the norm vs. going back and fixing later. As a result now I frequently see my applications running at client's offices and think to myself "holy crap, that's fast". Another side benefit is that it keeps all my "fun" applications over on another more current machine and separate from work.
Re: Developing When Your Computer is too Fast
#6Nice work. But be careful about relying entirely on something like this. There are more than just seek time differences between hard disks and SSDs: they have different internal cache behavior, different latency variances, queuing differences (depending on how the devices are configured and how you're using them) etc.
This seems like it'll get you 80% of what you want. But it'd be useful to have an actual disk to test on as well.
Re: Developing When Your Computer is too Fast
#7I can see this work, but honestly wouldn't it make more sense not to use an older computer? They are typically cheap and you don't have to suffer when you don't develop speed critical code.
Re: Developing When Your Computer is too Fast
#8Nice work. But be careful about relying entirely on something like this. There are more than just seek time differences between hard disks and SSDs: they have different internal cache behavior, different latency variances, queuing differences (depending on how the devices are configured and how you're using them) etc. This seems like it'll get you 80% of what you want. But it'd be useful to have an actual disk to tes…
To further this.
I think this is a great idea, but having worked on benchmarking database structures in the past, I'd be weary of using them for any type of real benchmark.
For one, trying to model a real disk would get very complicated very fast. Say, the access time of the disk will be a function of the position on disk, so it would be unrealistic to get random delays when scanning a large chunk of contiguous data or by just having a few delays in a random-access heavy load would also be extremely unfair.
In short, trying to model complicated disk latencies is pretty hard, and usually if you are programming with some model of disk in mind, building a disk latency simulator under that same model may end up giving you a false sense of security.
For what it's worth, I'd favor getting a cheap hard disk and trying the load there instead.
Re: Developing When Your Computer is too Fast
#9The point he's missing is that you don't have to develop software on the same computer you test it on. The best solution is to have a separate test computer that's appropriately slow. In fact, most people probably already have an old one lying around that they could use.
And regardless of speed, it's good to test your software on a variety of systems.
Re: Developing When Your Computer is too Fast
#10Fun, but the good thing about slow computers is that they're also the cheapest; it's far more economical to just buy an old box for a couple hundred dollars (or even cheaper).
Sure, but then I have to carry around another computer or two when I want to work within a particular assumption.
Now, I can say, ``What if this box were really slow to respond to network requests 10% of the time?'' and just do it.