Quick tips for fast applications

Just a short blog today

We sometimes get requests to look at performance issues. These are 10 points to consider.

1. If you probably never need something, don’t always get it ready. A typical example of this would be not to load a rarely used resource (such as a specific DLL) until you are about to use it for the first time. You get a faster startup and a smaller memory image. True, there is a delay when you first use the functionality but this will normally be in response to user action. Given the differences in speed between humans and computers, the user probably won’t notice a small delay. They will notice a longer delay if you load up several at startup.

2. Cache intelligently. If you are constantly allocating and deallocating the same sorts of object or the same Struct in unmanaged code then you are probably best off managing a cache of these objects than giving the heap manager extra work.

3. Consider your algorithms. High level approaches are flexible. Collections are powerful. Simple and low level is generally cheap.

4. Don’t do things more often than you need to. If you have a loop, only the things that change inside the loop should be inside the loop. You know this, of course… but it crops up more often than you would imagine.

5. Keep the UI responsive. This is something that Linux does rather well. It doesn’t make things faster. It actually makes them slower because the logic is more complex and UI interrupts the thread doing the real work. However, users judge application performance by how rapidly it responds to them. It is generally good to put long running tasks on worker threads and keep the UI thread for UI.

6. Don’t poll if you can use events/delegates. Why burn extra cycles?

7. Play well with others. Try to use system resources sparingly. You are not the only application on the system. If you are careful not to waste resources other applications will run better and so will you because you are not competing as much for resources.

8. Break rule 7 when you are the only application on the system. SQL server is a classic example of this. It grabs everything up front because it wants to be the only thing running on the box. SQL server is very performant.

9. Avoid network roundtrips.

10. Keep things that you will access at around the same time in the same bit of memory. Memory is accessed in pages. You are going to get a 4K read whether you ask for 4K or 2 bytes. You might as well get value for money from the read.

Signing off

Mark

Comments

• Anonymous
  October 05, 2005
  Nice one Mark...
• Anonymous
  October 05, 2005
  In regards to keeping the UI responsive, NEVER do anything that may block on a UI thread. In other words, accessing the disk is something that will almost always block the first time. Even if you think it's only a few bytes from a local disk, you may be 20th in the queue on a heavily loaded system. Accessing the network is pretty much guaranteed to block. Even things you don't realize may be going over the network, such as network address lookups or username lookups will block.
  
  Writing programs that work this way happens to be a bit more complicated, but I write programs that often run on heavily-loaded systems and I hate unresponsive UIs, so I have to do it.
• Anonymous
  October 05, 2005
  Thanks for the comment and the link, msvista
  
  Hi Gabe. You are right that it does involve a bit more work and a lot more thought to write highly effective code. It marks a software engineer out from a coder.
  
  All too often, you find highly multithreaded apps with unresponsive UIs and this is very often because they do the heavy work on the main thread and farm out the UI. As Gabe points out, you have to keep sending messages because it is the most natural thing in the world to send a message to a bit of UI which is managed by a blocked thread. SendMessage is synchronous and so you now block and stop servicing your message queue. Then someone sends you a message and they block. It won't hang unless you are in a circular message loop but it will serialise your process horribly.
• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=marklon-quick-tips-for-fast-applications