>>As the others have said - you do not need a stringbuilder.
>>
>>
>>You make the situation worse by using a string builder
>>
>>Explanation
>>This creates one extra string on the heap
>>
>>
>>return tcSearchIn.Replace(tcSearchFor, tcReplace);
>>
>>
>>Next is worse
>>
>>StringBuilder sb = new StringBuilder(tcSearchIn);
>>return sb.Replace(tcSearchFor, tcReplace).ToString();
>>
>>
>>The stringbuilder, initialized with tcSearchIn, holds a char array presentation of the string
>>This construct creates
>>(1) a char array on the heap
>>(2) a new string on the heap
>>
>>If the solution without the stringbuilder uses something like 100 Mb (temporarily), the solution with the stringbuilder uses 200 Mb.
>>The extra 100 Mb is used for the char arrays
>
>Initially, we had it like that. But, for very large memo fields which would need some replaces, using that would take too long. This is why we adapted the StrTran() method to use a StringBuilder().
>
>Would you recommend I leave this StrTran() as is for the default and create StrTranFromString() for a specific location where I know the string to use will not be big?
If you need a StrTran where multiple replaces will be done on the same string (large memo fields) and you know that using a stringbuilder in this case is better, then perhaps create a separate class, eg MultipleStrTran
But only use that if you have multiple replaces - and multiple is more than two. You have to do some testing to find out when a stringbuilder becomes considerably faster. A combination of string length and the number of times a replace has to be done on the same string
But in this case - where you only do one replace - called a million times
Using a stringbuilder puts pressure both on the memory and the cpu
- instantiating a million stringbuilders, allocating them on the heap
- instantiating a million char arrays, allocating them on the heap
- garbage collection of a million stringbuilders + heap compaction
- garbage collection of a million char arrays + heap compaction
This is all work that is not necessary in this particular case
Gregory