.NET apps. Looking after the bits and bytes

I am soon to develop a Win Forms app that will run on traders' machines and the main concern is to have the app use as little memory as possible. Ever single line of code needs to be written with this in mind.

What are areas I need to take into account?

Of course you will say to do any complex processing on e.g. the database and not the client but what else?

I'm looking for advice along the lines of, don't use int64 instead of int32, use data structure x instead of a D开发者_如何学Pythonictionary if you're not planning to search the collection often, call the garbage collector more often, don't cache data on the client etc ... I'm just making things up now but hopefully you get what I'm asking for

Cheers

Unless you're using a lot of data you won't see a huge difference between an int64 and an int32. 1,000 int32's vs 1,000 int64 is only about 4K in difference. The standard for integral values is usually an int which maps to an int32 so I'd recommend using that unless you have a specific need for 16 or 64.

Here's a great post by Rico Mariani who is the performance guy at Microsoft. The link in his article is now dead but he talks about 97% of your code doesn't need to be prematurely optimized. You can spend a week tuning your app and finding the best data structures but that one call to the web service hosted on the moon is going to slow down your entire app. Worry about the web service call first and once you've tweaked that as much as you can then worry about data type optimizations.

Did the people that write the spec understand what a memory bound app really means? Would you rather have an app that takes 10 seconds every time to retrieve cacheable data from a database. Or would you rather have an app pre-cache the data and "waste" 2 MB of memory? Me, I'm for the latter and I think most users are, too.

But you've got a spec to follow so I'll stop preaching. Check out this MSDN magazine article on .Net optimizations. I think you'll find some great advice in it.

Use a CLR memory profiler to see how the memory is being used.

Wherever semantically acceptable, use structs instead of classes for things that there will be a lot of. If you have arrays of structs, be mindful of the word alignment and the associated overhead. .NET may do things with memory that you don't expect, so test your assumptions before relying heavily on them.