There are many other good practices to adopt when writing code in the .NET Compact Framework. They can help drive your application towards a smaller memory footprint and ultimately better performance. We will cover some of these practices here.
String manipulation is a common operation in any application. Throughout the sales force application you have been using the + operator to concatenate strings. The String class is immutable. This means that each time you concatenate strings in the preceding fashion it creates a new string object. This can lead to inefficient memory utilization (and more work for the garbage collector).
You can improve the memory utilization of strings in your application using the StringBuilder class. Let's take a look at the performance differences between these two methods shown next. Create a new form and place two buttons on the form. Write the following code in the click event of the two buttons:
private void btnStringConcat_Click(object sender, EventArgs e)
{
String _temp="";
for (int i = 0; i <= 10000; i++)
{
_temp = _temp + "test";
}
MessageBox.Show("Done!");
}
private void btnStringBldr_Click(object sender, EventArgs e)
{
StringBuilder _temp = new StringBuilder();
for (int i = 0; i <= 10000; i++)
{
_temp.Append("test");
}
MessageBox.Show("Done!");
}
The first function in the preceding code performs 10,000 string concatenations while the second function uses the StringBuilder to perform 10,000 appends. Run the application and click on the first button (btnStringConcat). After that, close the form. A .stat file will be generated in the root folder of the mobile device. Take note of the following counters (which show the amount of string objects allocated, their size in bytes, and so on).
Managed String Objects Allocated 10027 Bytes of String Objects Allocated 400140456 Garbage Collections (GC) 438 Bytes Collected By GC 407222100
Now run the same application again and click the second button (btnStringBldr). Another .stat file will be generated. Now take note of this second set of counters.
Managed String Objects Allocated 39 Bytes of String Objects Allocated 262584 Garbage Collections (GC) 1 Bytes Collected By GC 296332
The first thing you will immediately notice is that with the StringBuilder class, fewer managed string objects are allocated. The size of the allocated objects is also much smaller. This equates to less memory traffic. It is, therefore, a good idea to use the StringBuilder class whenever possible for strings that change frequently.
There are a few good practices to keep in mind when manipulating Windows Forms. Let's take a look at some of them in the following sections.
You should generally use the BeginUpdate and EndUpdate methods for controls that offer them, such as the ListBox, ComboBox, ListView, and TreeView controls. The BeginUpdate method prevents the control from repainting itself until the EndUpdate method is called. It is typically used to prevent the control from repainting itself when it is being populated. For example, the following code snippet prevents a ListBox from repainting itself while it is populated with 3,000 items.
You should similarly use the SuspendLayout and ResumeLayout methods when you plan to reposition any controls on the form. SuspendLayout will suspend any layout logic while changes are made to the controls on a form until ResumeLayout is called. Let's take a look at how these functions can be used:
public void ChangeControls()
{
this.SuspendLayout();
button1.Location = new Point(50,50);
button1.Size = new Size(100,100);
button1.Text = "Test";
this.ResumeLayout();
}
Forms with large numbers of controls can sometimes take some time to load on the mobile device. If a form is expected to be reused many times throughout the application, you should consider caching the form and using the Show and Hide methods of the form to control its visibility.
For this same reason, you should not perform lengthy operations (such as populating data on the form) in the Show event of the form. Doing so will cause the UI to experience a period of inactivity (the form becomes visible only after the Show event has executed). This isn't good for your users because they will experience lower UI responsiveness.
In the same vein, you should also abstain from making calls that block the UI in any way. Consider using threads or asynchronous calls when you need to make extended function calls.
When manipulating large XML data files, there are a few ways to improve memory utilization and performance. They are outlined in the following sections.
You should consider using XMLTextReader and XMLTextWriter instead of XMLDocument. This is because XMLDocument uses more memory and also builds an untyped object model using a tree, which performs inefficiently.
Tip
When to use XMLDocument
XMLDocument can be used, however, for smaller XML documents (smaller than 64KB).
You can also set the IgnoreWhiteSpace and IgnoreComments property values to true in order to increase the performance of the XMLTextReader and XMLTextWriter. You can set these settings in the following fashion:
XmlReaderSettings _settings = new XmlReaderSettings();
_settings.IgnoreWhitespace = true;
XmlReader reader = XmlReader.Create("test.xml", _settings);
When serializing or deserializing large amounts of XML data, you should consider building a custom binary serialization mechanism (using the BinaryReader and BinaryWriter class). This is because XML serialization produces large amounts of textual data (tag names, attribute names, and so on) that takes up more memory than necessary. You can also consider Microsoft's GZIP compression (covered earlier) to compress XML data for storage or transmission.
XML that is more attribute-centric (uses attributes to store data) rather than element-centric also performs faster during deserialization.