Improving .NET application performance
The last two days I was involved in a somewhat unusual activity - detecting, measuring and clearing performance bottlenecks. I have no real experience in this area (well, recently I diagnosed a performance problem, but it was too obvious - excessive logging in a file, while opening and closing it on each call). So it took some time to familiraize myself with the topic and to try some .NET profilers - JetBrains DotTrace and CLR Profiler. Unfortunately JetBrains DotTrace (EAP version) did not help me much - I was having difficult time trying to understand how it works, since the documentation is really scarce at this point. It also crashed while trying to make huge memory dumps (1 GB), so I gave up on it. I looked at Red Ants Profiler video and it seems a bit better for a newbie, but I have not used it for real, so I can't tell. The CLR Profiler is not a gold-plated tool, but it worked fine and was actually somewhat helpful.
Today I was trying to find out which worked better: (a) File.ReadAllText() or (b) calling first File.ReadAllBytes() and then converting them to char[] and then encoding them as UTF8 string. Interestingly, inspecting WorkingSet and GC.GetTotalMemory(false) indicated that the used memory was less after File.ReadAllText(). But the CLR Profiler showed that it has allocated more memory. I wonder how this is possible? Am I measuring the wrong thing or maybe some garbage collection takes place within File.ReadAllText(). The (b) approach is a bit faster than (a), so I ended up using (b).
UPDATE: actually the (b) approach will not work that easily. There are a few marker bytes in the beginning of some text files that indicate the encoding, so you need an extra processing to make it work.
Btw, it appears that it is not a good idea to profile .NET application memory using just the the TaskManager. More details here.
Today I was trying to find out which worked better: (a) File.ReadAllText() or (b) calling first File.ReadAllBytes() and then converting them to char[] and then encoding them as UTF8 string. Interestingly, inspecting WorkingSet and GC.GetTotalMemory(false) indicated that the used memory was less after File.ReadAllText(). But the CLR Profiler showed that it has allocated more memory. I wonder how this is possible? Am I measuring the wrong thing or maybe some garbage collection takes place within File.ReadAllText(). The (b) approach is a bit faster than (a), so I ended up using (b).
UPDATE: actually the (b) approach will not work that easily. There are a few marker bytes in the beginning of some text files that indicate the encoding, so you need an extra processing to make it work.
Btw, it appears that it is not a good idea to profile .NET application memory using just the the TaskManager. More details here.




1 Comments:
I have used AQTime with considerable success on .Net performance tuning. I would thoroughly recommend it.
By
Timothy, at
22 July, 2006 00:01
Post a Comment
<< Home