The impact of performance is much more readily apparent in .NET Compact Framework applications. The mobile devices commonly have a CPU that is 10 times slower than your desktop CPU, and possibly up to 100 times less RAM than a desktop or server. In Agile or XP development, the mantra is often to ignore performance considerations until necessary – I don’t think you can apply that to .NET CF development or it will really bite you in the end. You don’t have to go nuts and optimize everything up front, but there are some very important things to keep in mind when developing a Windows Mobile application…
Standard .NET Framework Performance Considerations
Many of the standard .NET Framework performance best practices can become apparent very quickly including…
- Object Boxing and Unboxing. Use generics wherever possible and avoid ArrayLists and type conversions.
- String and StringBuilder. Need to perform lots of string concatenations? Use a StringBuilder instead of the ‘+’ operator. When you use the ‘+’ operator, a new string object is created each time you concatenate, increasing memory usage. The ‘+’ operator is much slower if you’re concatenating a large number of strings.
- Memory leaks.
- When doing .NET CF development, if an object implements the Dispose() method – call it when you are finished with the object.
- One of the most common causes of memory leaks is unhandling events when they’re no longer needed. If you manually hook up an event with the ‘+=’ operator, ensure you’re unhandling it when finished with the ‘-=’ operator.
- Pre-allocate collections if possible. Standard .NET behavior is to automatically double the size of a collection when the upper limit is reached while adding items. If you know the number of elements that are are going to be in a collection, pre-allocate the size of the collection when instantiating it.
- Don’t use Exceptions for flow control in an application. Exceptions are an expensive operation, performance wise. I’m not saying don’t use exceptions, but don’t use them in areas where you can perform simple checks to prevent them from being thrown. For example, if you might divide by zero – perform a simple check before the operation occurs rather than handling a DivideByZeroException. The check is much less expensive than the exception.
.NET Compact Framework-Specific Performance Considerations
However, the .NET Compact Framework is different than the full framework in many ways, leading to a slew of .NET CF specific performance considerations…
- Avoid making virtual function calls. They are up to 40% slower than instance and static function calls. I don’t completely understand the reason for this, but you can read more about it here if you’re interested.
- There are a few things in .NET CF that are slow because of virtual calls and object boxing/unboxing. These include:
- Reflection. Very slow in .NET CF.
- XML Deserialization and DataSets. Extremely slow because reflection is slow.
- Avoid creating many copies of Form objects. Creating a Form is an expensive operation, and unused Form objects are a common cause of memory leak issues. You may want to create your Forms once and cache them in the background for reuse.
- You can increase the speed of binding data to controls by using the BeginUpdate and EndUpdate methods on a control before and after your data binding occurs. This will cause the control to not repaint until the binding is finished.
- Cache expensive resources. For example, don’t create many different copies of a web service client. Create a single, cached instance of it that can be used throughout your application.
- Always test your application on a wide range of physical devices. If the target device is known, at least test on that device. Some things seem to perform much betterwhen running on the emulator or when executing unit tests on your desktop environment.
- This is a more general performance testing best practice, but always test with real data and real quantities of data. This can really bite you on deployment of your application. I know this from experience – a great example is that deserializing a few hundred objects is MUCH much faster than deserializing 10,000 objects. In my experience, deserializing 7,000 very simple DTO objects from an ASMX web service was taking up to 20 minutes in some cases. To alleviate the issue, we ended up switching to a JSON web service, which was much faster to deserialize.