Coding for Performance : Strings

In .NET, strings are immutable. Once created, they exist forever in that state until garbage collected. This means that any modification of a string results in creation of a new string. Fast, efficient programs generally do not modify strings in any way. Think about it: strings represent textual data, which is largely for human consumption. Unless your program is specifically for displaying or processing text, strings should be treated like opaque data blobs as much as possible. If you have the choice, always prefer non-string representations of data.

String Comparisons

As with so many things in performance optimization, the best string comparison is the one that does not happen at all. If you can get away with it, use enums, or some other numeric data for decision-making. If you must use strings, keep them short and use the simplest alphabet possible.

There are many ways to compare strings: by pure byte value, using the current culture, with case insensitivity, etc. You should use the simplest way possible. For example:

String.Compare(a, b, StringComparison.Ordinal);

is faster than

String.Compare(a, b, StringComparison.OrdinalIgnoreCase);

which is faster than

String.Compare(a, b, StringComparison.CurrentCulture);

If you are processing computer-generated strings, such as configuration settings or some other tightly coupled interface, then ordinal comparisons with case sensitivity are all you need.
All string comparisons should use method overloads that includes an explicit StringComparison enumeration. Omitting this should be considered an error.
Finally, String.Equals is a special case of String.Compare and should be used when you do not care about sort order. It is not actually faster in many cases, but it conveys the intent of your code better.

ToLower, ToUpper

Avoid calling methods like ToLower and ToUpper, especially if you are doing this for string comparison purposes. Instead, use one of the IgnoreCase options for the String.Compare method.

There is a bit of a tradeoff, but not much of one. On the one hand, doing a case-sensitive string comparison is faster, but this still does not justify the use of ToUpper or ToLower, which are guaranteed to process every character, where a comparison might not need to. It also creates a new string, allocating memory and putting more pressure on the garbage collector. Just avoid this.

Concatenation

For simple concatenation of a known (at compile time) quantity of strings, just use the ‘+’ operator or the String.Concat method. This is usually more efficient than using a StringBuilder.

string result = a + b + c + d + e + f;

[/csharp]

Do not consider StringBuilder until the number of strings is variable and likely larger than a few dozen. The compiler will optimize simple string concatenation in a way to lessen the memory overhead.
<h2>String Formatting</h2>
String.Format is an expensive method. Do not use it unless necessary. Avoid it for simple situations like this:
<pre>
string message = String.Format("The file {0} was {1} successfully.", filename, operation);

Instead, just do some simple concatenation:

string message = "The file " + filename + " was " + operation + " successfully";

Reserve use of String.Format for cases where performance does not matter or the format specification is more complex (like specifying how many decimals to use for a double value).

ToString

Be wary of calling ToString for many classes. If you are lucky, it will return a string that already exists. Other classes will cache the string once generated. For example, the IPAddress class caches its string, but it has an extremely expensive string generation process that involves StringBuilder, formatting, and boxing. Other types may create a new string every time you call it. This can be very wasteful for the CPU and also impact the frequency of garbage collections.

When designing your own classes, consider the scenarios your class’s ToString method will be called in. If it is called often, ensure that you are generating the string as rarely as possible. If it is only a debug helper, then it likely does not matter what it does.

Avoid String Parsing

If you can, reserve string parsing for offline processing or for during startup only. String processing is often CPU-intensive, repetitive, and memory-heavy—all things to avoid.

 

For all your application development needs, visit www.verbat.com for a fiscally conscious proposal that meets your needs ( So I can keep this blog going as well!!!!)

Alternatively click through the link   if you found this article interesting. (This will help the companies Search engine rankings)