.NET news » Performance

Your own extensible and configurable Thread Pool

The try/catch block is used to capture thrown exceptions and to allow an application to recover gracefully from the problems that caused them. This article has been created to determine if the try/catch block causes a substantial performance penalty.

This article has two aims. Firstly, there are a series of five exercises that detail the process of successfully multi-threading a sequential algorithm with timely progress display in the UI. It also provides an implementation of a thread local storage class which can help realise the performance promise of many-core machines.

In this article, we will look into JIT optimizations, with specific focus on inlining.

A framework for object serializiation/deserialization that is many times faster and yields compact output.

Nowadays, multi-core processing is a growing industry trend as single core processors rapidly reach the physical limits of possible complexity and speed. It's obvious that if such wonderful hardware exists, it should be supported in .NET, shouldn't it? To check this I looked for a well-known easy-parallelizable algorithm. The benchmark should have handled different .NET parallelizing techniques with memory and mathematical operations. In my opinion, the best algorithms that fit these requirements are QuickSort and Matrix multiplication.

Please take into account, that this article doesn't describe any algorithms' optimization techniques. Instead it shows, how to parallelize your C# code and compares the performance of different approaches.

How much faster will implementing "the generic bad algorithm" in SSE2 make it?

There are a lot of ways to improve performance in web applications. One of the simplest but most effective methods is to cache images on the client. In this article I would like to show how we implemented image caching for our DotNetNuke website.

I work with performance-critical software that often requires some form of cache to function efficiently. However, there is also often a need to constrain memory usage, so I set out to create a high-performance cache with a maximum size.

The Caching Application Block's provider mechanism lets you create a custom provider that stores cached data anywhere you want. It was this that made me wonder if it was possible to cache data within or through a web service, which would allow the provider to cache its data almost anywhere—remotely or locally—without having to write specific code that is directly integrated within Enterprise Library.

The principle is simple enough. Instead of having the backing store provider within the Caching Application Block interact directly with the backing store (the usual approach, as implemented in the Isolated Storage provider and Database provider), the backing store provider simply packages up the data and sends it to a web service..