9 posts tagged with "performance"

We had a horribly pernicious timeout problem recently. It was occurring in a .Net 2.0 application written to retrieve reports from SQL Server 2005 Reporting Services via its web services interface. The query behind the report was a bit large, but typically would run under 30 seconds. We had judged that new indexes were out of the question because of their impact on the already slow program that loads the key data. All of the sudden, we started getting continuous timeouts. After a couple of days, the underlying query was up to 15 minutes execution time!

In the end multiple interacting problems had to be solved in order to get the reports running properly. For the past few weeks they've been running without a hitch.

Although very handy, C#'s foreach statement is actually quite dangerous. In fact, I may swear off its use entirely. Why? Two reasons: (1) performance, and (2) predictability.

This article is part of the series An Exercise in Performance Tuning in C#.Net.

After a month-long hiatus — too much work, too fast and furious for posting — I'm back to the last posts in the series on real-world performance tuning. The point of these postings hasn't been to glorify my ability to tune a C# data processing application, but rather to share what I've learned in attempts to do so.

Where to next? Turns out my next steps were false starts, at least insofar as tuning is concerned. Still, there were some lessons (or should be) from these dead ends.

This article is part of the series An Exercise in Performance Tuning in C#.Net.

As I look at the code I now have, I wonder if the fileLines variable is an unnecessary intermediate step. Can I rewrite so that stream.ReadLine() is passed directly into the parsing? If I do so, I'll be leaving the file open longer, but since no other application should be attempting to access the file, I'm okay with that. This means moving the open file command into MyClass.ProcessFile().

This article is part of the series An Exercise in Performance Tuning in C#.Net.

It's time to stop ignoring the 800 pound gorilla in the room: System.String. Scrolling all the way over in the Allocation Graph, it is clear that strings take up most of the memory, and it seems logical that most of that comes from the input file.

(removed link to missing image file)

This article is part of the series An Exercise in Performance Tuning in C#.Net.

At this point I did not re-run the profiler but continued investigating memory allocation. Here's an interesting looking result:

(removed link to missing image file)

This is not part of my series on performance tuning a specific app.

Problem​

I have a Registry class in which I want to place a generic collection of objects. In this way I can add new items to the registry on the fly (i.e. from a user application), without having to recompile the library containing the the class. What is my best option, in terms of performance, for a .Net 2.0 collection to hold my mixed-bag of objects? I'll be referring to these with a string name.

This article is part of the series An Exercise in Performance Tuning in C#.Net.

Where else could I improve performance? I thought I should inspect the memory usage and garbage collection. For that I found a great little tool from Microsoft, the CLR Profiler, which I found through the MSDN Patterns & Practices series of guides on application performance and scalability. The specific article that I found most helpful was How To: Use CLR Profiler.

This article is part of the series An Exercise in Performance Tuning in C#.Net.

The application I was working on makes a number of calls to a remote server to perform operations. These calls are made through a proprietary API implemented in .Net. Speaking with the vendor, I discovered two really dumb mistakes that were killing our performance.