.Net Application Performance Tips

I have recently finished reading “Improving .Net Application Performance and Scalability” book by a bunch of authors. If you do not have my privilege of going to work by train and want to save on reading 1000+ pages (not all of the reading is that entertaining) here is a small resume of the book. Note that most of the bullets probably contradict to others “Design Patterns” books.

• Use single large assemblies instead of small ones
• Use sealed keyword when defining classes
• Use Properties instead of Fields for returning data and simple checking
• Set unneeded variables to nulls before making long-running calls
• Consider using Weak References (e.g. for caching)
• Pre-allocating chunks of memory is not as important in managed code as in unmanaged – here usually the compiler is smarter than the human
• Pre-init collections with their approximate size
• Avoid Finalize-Dispose pattern unless absolutely necessary
• Use asynchronous pattern only when necessary (more efficient making synchronous calls if no work items are being done at the same time)
• Use ThreadPool to create threads.
• Always keep default settings unless testing has shown that the defaults are not good
• Use Ildasm.exe my.dll /text | findstr box to check if there are boxing/unboxing overhead in your code
• Do not throw exceptions if possible – exception path should be followed no more than 0.1% of all executions. If it is more often consider returning error codes
• Do not re-throw. It takes same amount of time to re-throw as when throwing original exception
• Prefer for loop to foreach if possible
• Avoid interface programming, use always concrete classes if possible
• Avoid reflection, and late binding whenever possible
• Use [SuppressUnmanagedCodeSecurity] for P/Invoke or COM Interop unmanaged calls when you know who is on the calling stack (it won’t check if you are allowed for each stack).
• For timers always use System.Threading.Timer unless explicitly need other features
• ASP.Net: use Server.Transfer instead of Response.Redirect for same server transfers
• SQL: Preconfigure SQL number of pool connections to preload some of them on start. By default 0 preloaded and the maximum is 100
• SQL: if only one row is returned use Output parameters and ExecuteNonQuery
• SQL: add SET COUNT ON in your stored procedures if you do not care how many rows are returned after each statement
• SQL: Cache same SQL parameters passed to a stored procedure
• SQL: Use CommandBehaviour.SequentialAccess if you do not need random access to the data
• SQL: Explicitly specify SQLParameter types to aoid overhead with determining its type at runtime
• SQL: Try to use while loops instead of cursors
• SQL: If using cursors try forward-only, read-only
• SQL: Avoid cursors used over temp tables (make those tables permanent if possible)
• SQL: Every table needs a clustered index
• SQL: Do not bother with indices on not highly selected columns (i.e. with not many different values, e.g. bit)
• SQL: Keep clustered index keys as small as possible
• SQL: Create indexes for all columns used in Where clause
• Check SQL Server: General Statistics performance counter to see that logins/sec = logouts/sec = 0 after the program has initialized
• Use StringBuilder only for unknown number of concatenations. Otherwise use str1 + str2 + str3
• String.Compare(str1, str2, bool case) is the most efficient of all string comparators
• Use “jagged” arrays instead of multidimensional arrays
• Prefer StringCollection over ArrayList to store strings
• Always use different performance counters to monitor the application