Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As most people agree, encouraging developers to make fast code by giving them slow machines is not a good idea. But there's a point in that question. My dev machine is fast, and so I occasionally write code that's disturbingly inefficient, but that only becomes apparent when running it on other people's machines.

What are some good ways to temporarily slow down a turbocharged dev machine? The notion of "speed" includes several factors, for example:

  • CPU clock frequency.
  • Amount of CPU cores.
  • Amount of memory and processor cache.
  • Speed of various buses.
  • Disk I/O.
  • GPU.
  • etc.
share|improve this question

closed as too broad by MichaelT, durron597, GlenH7, Snowman, gnat Oct 2 '15 at 9:00

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Unpress the "Turbo button" ... no, wait. – LennyProgrammers Dec 2 '10 at 8:41
Here is the root of your problem: "Disturbingly inefficient". change your coding habit – Darknight Dec 2 '10 at 10:04
@Darknight: No, it's not that. You have to first make it right, then make it fast if needed. To know what to optimize, you have to test and find out what's the problematic part. Making things as fast as possible in the first place is waste of your time - and likely waste of doing it right. – Joonas Pulakka Dec 2 '10 at 10:13
Well I partly agree. However if you have an efficient coding habit to start of with; then as your "making it work right" you can spend less time later "making it faster". – Darknight Dec 2 '10 at 10:25
@Darknight: I think @Joonas is asking a very sensible question. The idea that just "changing your coding habit" is sufficient is not realistic. Here's an example: (…) AND, the idea that you can just time it on a slower machine without an IDE assumes that's enough to find performance bugs. Lots of people talk about profiling, but doing it (successfully) is another matter. What would really help me (& others I think) is what Joonas is asking for. – Mike Dunlavey Dec 2 '10 at 21:49
up vote 36 down vote accepted

Run your tests in a virtual machine with limited memory and only one core.

The old machines people still may have now are mostly Pentium 4 era things. That's not that unrealistic - I'm using one myself right now. Single core performance on many current PCs normally isn't that much better, and can be worse. RAM performance is more important than CPU performance for many things anyway, and by limiting a little more harshly than for an old 1GB P4, you compensate for that a bit.

Failing that, if you're willing to spend a bit, buy a netbook. Run the tests on that.

share|improve this answer
Or an elderish laptop. – user1249 Dec 2 '10 at 8:52
The problem with virtual machines is that none of them (AFAIK) supports IEEE 1394 (firewire) port. Some of my software uses cameras that are connected with firewire, so... – Joonas Pulakka Dec 2 '10 at 9:02
the real ones let you assign any PCI device to the VM – Javier Dec 2 '10 at 9:54
Could be a job for Xen - the virtual machine doesn't have a host O/S, but is the top layer in itself. Has a heavily Unix history, but can now support proprietary OSes. But I never used it, and don't know how much control you can have over a particular VMs performance and resources. – Steve314 Dec 2 '10 at 10:01
+1 A VM is highly tunable and provides exactly the environment you're after for testing. I use VMWare myself for this purpose. – Gary Rowe Dec 2 '10 at 12:29

The way to spot significant algorithm inefficiency is to profile you code. The way to catch memory overuse is to first understand how much memory your target uses have, and then design accordingly, and regularly test in that environment.

If you are writing threaded code, testing on multiple machines with differing CPU speeds will help highlight specific timing related bugs in your thread handling, but aggressive unit testing of thread logic is a must.

share|improve this answer
No, profiling won't catch algorithmic inefficiency. It'll show you where the program is spending its time if you need to speed it up, but not if you need to speed it up. – David Thornley Dec 2 '10 at 22:45
I think I am missing the distinction here. If you mean that profiling will not tell you IF you are being sub optimal, just where you are spending your CPU cycles, then I agree. That takes experience to make that judgement. – Ptolemy Dec 2 '10 at 23:27
@David Thornley & @Ptolemy: I think algorithm inefficiency or code hot spots are secondary to the core problem: "Is it too slow or not?" It's subjective, but it's also the most important question. If it doesn't feel slow in practice, then so what if your algorithm is inefficient? It does what it needs to do! Or if the program feels too slow regardless of highly optimal algorithms, then you may have to change the approach (architecture? programming language? something!) altogether. Having highly optimal algorithms are not an excuse for program slowness :-) – Joonas Pulakka Dec 3 '10 at 6:53
To reveal algorithm inefficiency, use progressively-sized data sets for testing. – rwong Dec 7 '10 at 9:07

Anything that you do to slow down your machine would probably be a hack.

Here are a couple of suggestions:

  • Use virtual machines
  • Profile the code on your machine, looking for bottlenecks
  • Use an old machine for "performance testing"
share|improve this answer
+1 for profiling – Matt Ellen Dec 2 '10 at 11:47
@matt what does that mean? – johnny Dec 2 '10 at 20:31
@johnny: I mean I am up voting because Jason has suggested profiling the application, which would hopefully find the source of performance bottle necks without the need to move to a slower system. – Matt Ellen Dec 2 '10 at 22:44

Install Virtual PC, create a hardware profile, create a virtual machine and start playing :)

share|improve this answer

Realise this is quite an old question, but for anyone else in this situation; you could try CPUKiller. It basically is a small app that you can configure to consume different %'s of your processor.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.