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.

Situation: We have a stored procedure running a query whose WHERE clause is given as a parameter. No, that's not the problem in and of itself, at least not today. (Treat this as a non-negotiable requirement for now). Within that WHERE clause there might be a query against a field, call it myField. This field is a varchar and wildcards are not used. Platform: SQL Server 2005.

Problem​

myField has been changed to a varbinary field and holds an encrypted value — thus can no longer query directly against it. How do we make this work?

Problem​

Your application is slow. Horribly slow. And that just isn't acceptable.

Problem​

You've transferred or run a bunch of stored procedure scripts, but you can't execute them. Reason - execute permission denied. You forgot to put a grant statement in your script.

Solution​

The trivial solution is, of course, GRANT EXECUTE ON {your proc name} TO PUBLIC. Slightly less trivial is to grant to a specific role, but most people needing this tip will only be using PUBLIC.

Wouldn't it be great to automate this for all stored procedures in the database? Well, here you go:

Problem​

On a Microsoft SQL Server 2005 installation with a linked server configured to "myserver" (which happens to be 2000), execution of a remote stored procedure (EXEC myserver.mydatabase.dbo.mysproc) fails with error:

Msg 7411, Level 16, State 1, Line 1
Server 'myserver' is not configured for RPC.

Problem​

Microsoft .Net Framework 1.1 and .Net Framework 2.0 don't play well together (as ASP.Net apps) on Windows 2003 Server 64 Bit Edition.

Solution​

either upgrade any ASP.Net 1.1 to 2.0 or switch to 32 bit compatibility mode. Of course switching to 32 bit mode will cause you to lose out on some performance benefits, but maybe you're okay with that (unless you're running under a very high load). Two easy steps:

Problem​

Need to convert an image from one format to another using .Net.

Solution​

Microsoft has really made this easy. The key is the System.Drawing.Image class, combined with the System.Drawing.Imaging.ImageFormat class.

Steps:

Problem​

In a .Net 2.0 Windows Forms application, user action causes a new

row to be added to a DataGridView control. When the viewport fills up, causing the vertical scrollbar to appear, the most recent entry is hidden "below the fold" — off the screen. Users want to see the latest entry at all times.

Breathing, eating, sleeping. Typing, gardening, speaking. These things Evolution's end — but not my own. Life begets life, begets continuous wonder and love. Ambition brings no love, births no wonder nor praise for the Universe. Life must be praise, not ambition. Must be love, must be passion mixed with sense mixed with openness. Open to the Mysteries, open to the wide skies above the plain and deep places hidden in the gorge. Open to the divine. Praise be to Thee, O Universe of limitless perfection. Grant that I may Live for Thee.