.NET news » Performance

One of the most sure-fire ways to improve a web application's performance is to employ caching. Caching takes some expensive operation and stores its results in a quickly accessible location. ASP.NET version 1.0 introduced two flavors of caching:

• Output Caching - caches the entire rendered markup of an ASP.NET web page or User Control for a specified duration.
• Data Caching - a programmatically-accessible, in-memory data cache for storing objects in the web server's memory.

For a more in-depth discussion on ASP.NET 1.x's caching capabilities, refer to Scott McFarland's Caching with ASP.NET and Steve Smith's ASP.NET Caching: Techniques and Best Practices articles.

In ASP.NET 2.0, the caching system has been extended to include SQL cache dependencies, cache profiles, and post-cache substitution for output cached pages. The Caching for Performance section of the ASP.NET 2.0 QuickStarts provides a good overview of ASP.NET 2.0's caching options. This article explores output caching in ASP.NET 2.0, starting with an overview of output caching and followed by a detailed look at creating pages that include both cached and non-cached markup using fragment caching and post-cache substitution techniques.

Provides code and techniques to enable developers to optimize serialization of data.

A super-fast flood fill algorithm and implementation, plus helpful optimization tips for image processing.

Process GDI+ images at blazing speeds, with no pointers or unsafe code. Eliminate the need for LockBits(), so you can edit the bits directly and update in real time.

Many diagnostic tools use the CLR Profiling API-even those that aren't strictly profilers. So if you've ever wondered how these tools work, a look at the Profiling API is a good start. In this column, you'll see how they work and look at some useful tips and tricks. You'll also find some essential resources in the "Other Profiling Resources" sidebar. To use the CLR Profiling API, you create a DLL using an unmanaged language-typically C++, then you set some environment variables that instruct the common language runtime (CLR) to load the DLL and allow it to use the Profiling API. When loaded, this DLL effectively becomes an extension of the CLR itself, receiving callbacks, requesting information, and making changes deep within the implementation of the CLR. The Profiling API can provide notification of many activities within the CLR and managed code, including the creation and destruction of appdomains, loading and unloading assemblies, JIT compiling functions, executing functions, throwing and catching exceptions, and doing garbage collections. Using the Profiling API, you can get information about parts of the application, such as names and locations of assemblies, descriptions of types and functions, and locations and layout of objects in memory. Finally, you can use the Profiling API to modify settings, instructions, and the like, including disabling optimizations in the JIT compiler, changing the intermediate language (IL) for a function, or even creating new types and functions..

This article is dedicated to the observable property design pattern, a very nice pattern used in the Microsoft .NET Framework, a possible memory leak problem with it, and gives a couple of ways to solve it.

Provides code and techniques to enable developers to optimize serialization of DataSets/DataTables.

Uncovering and correcting memory issues in managed applications can be difficult. Memory issues manifest themselves in different ways. For example, you may observe your application's memory usage growing unboundedly, eventually resulting in an Out Of Memory (OOM) exception. (Your application may even throw out-of-memory exceptions when there is plenty of physical memory available.) But any one of the following may indicate a possible memory issue:

• An OutOfMemoryException is thrown.
• The process is using too much memory for no obvious reason that you can determine.
• It appears that garbage collection is not cleaning up objects fast enough.
• The managed heap is overly fragmented.
• The application is excessively using the CPU.

This column discusses the investigation process and shows you how to collect the data you need to determine what types of memory issues you are dealing with in your applications. This column does not cover how to actually fix problems you find, but it does give some good insights as to where to start.

Appending to an XML file can be tricky with large files in terms of speed and memory usage. This article covers the options available in .NET.

A simple and fast random number generator that can be substituted in place of System.Random, with extra methods and fast re-initialization.