21

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.
12
  • 35
    Unpress the "Turbo button" ... no, wait. Commented Dec 2, 2010 at 8:41
  • 6
    Here is the root of your problem: "Disturbingly inefficient". change your coding habit
    – Darknight
    Commented Dec 2, 2010 at 10:04
  • 17
    @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. Commented Dec 2, 2010 at 10:13
  • 1
    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
    Commented Dec 2, 2010 at 10:25
  • 4
    @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: (stackoverflow.com/questions/926266/…) 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. Commented Dec 2, 2010 at 21:49

5 Answers 5

39

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.

7
  • 1
    Or an elderish laptop.
    – user1249
    Commented Dec 2, 2010 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... Commented Dec 2, 2010 at 9:02
  • the real ones let you assign any PCI device to the VM
    – Javier
    Commented Dec 2, 2010 at 9:54
  • 3
    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.
    – user8709
    Commented Dec 2, 2010 at 10:01
  • 1
    +1 A VM is highly tunable and provides exactly the environment you're after for testing. I use VMWare myself for this purpose.
    – Gary
    Commented Dec 2, 2010 at 12:29
11

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.

4
  • 1
    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. Commented Dec 2, 2010 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. Commented Dec 2, 2010 at 23:27
  • 4
    @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 :-) Commented Dec 3, 2010 at 6:53
  • 1
    To reveal algorithm inefficiency, use progressively-sized data sets for testing.
    – rwong
    Commented Dec 7, 2010 at 9:07
10

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"
2
  • @matt what does that mean?
    – johnny
    Commented Dec 2, 2010 at 20:31
  • 1
    @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
    Commented Dec 2, 2010 at 22:44
9

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

4

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. http://www.cpukiller.com/

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