.NET news » Performance

A distilled methodology for detecting and isolating NHibernate-related performance and scalability issues

The Simple Performance Chart is a UserControl that is designed and developed to display varying performance data like reads per second on a disk drive, the bandwidth for a server, or free CPU resources, in a visual, clean manner. It can be controlled by a built-in Timer, which makes synchronized display of values possible. The control offers several formatting options like border style, line colors and styles, widths, a background gradient, and so on.

An article on improving the performance of an algorithm by replacing integer divisions

Software must operate at a speed that is acceptable to the end user. Often large improvements can be made by improving the speed of short-lived but heavily used routines. The speed of these can be accurately measured using the .NET 2.0 Stopwatch class.

Explore ways to reduce page load time, manage state efficiently, scale back on memory use, handle resources better, and improve data access in your ASP.NET applications.

Useful concurrency classes and small test bench in C#

Slow and unpredictable are words that typically characterize I/O operations. When an application performs a synchronous I/O operation, the application is basically giving up control to the device that is doing the actual work. For example, if an application calls the StreamRead method to read some bytes from a FileStream or NetworkStream, there is no telling how much time will pass before that method returns. If the file being read is on a local hard drive, then Read may return almost immediately. If the remote server housing the file is offline, then the Read method may wait several minutes before timing out and throwing an exception. During this time, the thread making the synchronous request is tied up. If that thread is the UI thread, the application is frozen and stops responding to user input.

A thread waiting for synchronous I/O to complete is blocked, which means that thread is idle but is not allowed to perform useful work. To improve scalability, many application developers create more threads. Unfortunately, each thread introduces significant overhead such as its kernel object, user-mode and kernel-mode stacks, increased context switching, the calling of DllMain methods with thread attach/detach notifications, and so on. The result is actually reduced scalability.

An application that wishes to remain responsive to the user, improve scalability and throughput, and increase reliability should not perform I/O operations synchronously. Instead, the application should use the common language runtime (CLR) Asynchronous Programming Model (APM) to perform asynchronous I/O operations..

Defining (rather loosely) ad hoc queries as SQL commands built as strings by an SQL client application and submitted to SQL Server.

Fast stream compression using a ported minilzo for .NET.

Performance tips and hard-core tricks that change core runtimes, not for the faint hearted.