.NET news » Performance Performance Rss Feed

ASP.NET Site Performance Secrets
Author: Matt Perdeck
Average rating:  / 0
(0 reviews)
More .NET Performance books

The Baker’s Dozen: 26 Productivity Tips for Optimizing SQL Server Queries (Part 1 of 2)

There’s an old programmer adage: “First you make it work, then you make it work fast.” Well, when writing T-SQL queries, you can do both, if you have some knowledge about how the SQL Server optimizer works. This will be a two-part article. In part one, I’ll start with fairly basic optimization tips and techniques for writing SQL queries. In part two, I’ll cover more advanced techniques.

Gathering Diagnostics from Windows Azure

All systems require a degree of monitoring. We monitor on premise installations for usage, performance, outages, tracing, and for a multitude of other reasons. Services which are deployed on premise operate in a controlled environment. The organisation’s IT team is very much aware of what systems are running on the organisation’s servers. It is an [...]

read more

10 Apr 2012, 02:00:00   Source: Gathering Diagnostics from Windows Azure   Tags: Performance

C++ AMP: Introduction to Tiling in C++ AMP

In C++ AMP, the most common and first step to dialing up performance gains to the next level is through a technique called tiling. This article picks up where Daniel Moth’s introduction to C++ AMP left off, and explains how to tile your C++ AMP algorithms.
1 Apr 2012, 18:00:00   Source: C++ AMP: Introduction to Tiling in C++ AMP   Tags: Performance

Some nice performance features in Visual Studio 11

This sort of solution managment brings welcome relief.

21 Mar 2012, 16:17:00   Source: Some nice performance features in Visual Studio 11   Tags: Performance

C++: New Concurrency Features in Visual C++ 11

Explore the new Visual C++ technologies that allow applications to run independent or semi-independent activities in parallel and provide mechanisms for synchronizing the way these activities handle data to avoid race conditions.
29 Feb 2012, 17:00:00   Source: C++: New Concurrency Features in Visual C++ 11   Tags: Performance

Measuring IE Performance

The Building Windows 8 blog has an interesting article on how we measure IE perf.

Recommended reading :)

17 Feb 2012, 09:25:00   Source: Measuring IE Performance   Tags: Performance

Improving .NET Application Performance and Scalability

This series can still be found here:

http://msdn.microsoft.com/en-us/library/ff649152.aspx

While some of the content is stale since it refers specifically to .NET 2.0 I think all of the conceptual content broadly applicable (even beyond managed code systems to software systems generally.)

If you're looking for it some time in the future you can find it again easily with bing.  I doubt that they'll get rid of it entirely for a very long time.

11 Jan 2012, 16:41:00   Source: Improving .NET Application Performance and Scalability   Tags: Performance

Forecast: Cloudy: Windows Azure Caching Strategies

Joseph Fultz maps Windows Azure caching capabilities to caching strategies for output, in-memory data and file resources, balancing the desire for fresh data with the desire for the best performance.
2 Jan 2012, 18:00:00   Source: Forecast: Cloudy: Windows Azure Caching Strategies   Tags: Performance

Performance Guidelines for Properties

I can’t say I’ve asked the framework guidelines folks about this but I’m fairly sure there would be a lot of agreement from the guidelines gurus; so in the spirit of approximately correct advice I give you Rico’s Guidelines for Performant Properties.

I should start by saying I wish more people just used fields instead of committing these terrible sins with their properties.  If we had the notion of a type-safe, read-only field the world would be a better place.  Alas…

So, you’re using a property, the most important thing to remember is that it will seem very much like a field in all ways.  It looks like a field and feels like a field, people will expect it to perform like a field.  So with that in mind:

Accessing the property should not allocate any memory; people are going to use this thing in loops walking over whatever data structure you are presenting, they expect that this data is sitting around and being accessed. Accessing the property should not “synchronize” – if there is any locking to be done it should be done at a higher level than a single field, by the time you’ve acquired whatever object has the property on it, it should already be safe to read it. Accessing the property should not do any I/O, especially not any network I/O, again see above, by the time you’re reading the property the object offering it should have done whatever I/O was needed. Accessing the property should not be an operation with complexity greater than O(1) – that means no loops.  At all.  You could haggle me as high as O(lg(N)) if we’re talking about an property that is an “indexer” but no higher. Accessing the property should not have side-effects (i.e. it's strictly a read operation, it changes nothing)

What you’re left with is you can use your object state and the argument (if an indexer) to do a constant-time lookup, or log-time at worst, in an already existing data structure and immediately return the result.  That’s it.

Why?

Pit of Success is the only reason you need.  In my opinion, patterns more complicated than the above are doomed to fail.  If you allow say network access, an RPC or the like, on each property fetch, then you promote things like field-at-a-time access to remote data.  Not only is this astonishing to users of the API it is incredibly inefficient.  If you follow the rules above you soon realize that you must allow some kind of query to get the data you need and then you can use properties all you like to access that data.  That is a much better pattern, it leads to success.

Remember that if you allow things like I/O or synchronization you can easily get property access times that are measured in milliseconds, this simply will not do.  A typical interactive scenario might have a budget of say 100ms for prompt response and it might require access to several dozen properties just to paint the screen properly.  This has several issues:

If property access is say 1 millisecond then accessing 10 properties (not at all crazy) would be 10% of your overall budget – that’s nuts! The interactive code must be able to use your properties with confidence, that means they cannot block and should not be subject to large variability, else you get UI that is non-responsive for extended periods of time

Frequent access to properties is very common and therefore must be astonishingly cheap if only to keep a handle on the Joules your program consumes – an increasingly important metric for modern platforms.

From a time perspective, I like to see properties that have access time measured in nanoseconds.  Let’s say 10^-8s.  I can reasonably see systems with tricky indexing that might go has high as 10^-7 or even 10^-6.  When your time is getting to be 10^-5 or larger, you really need to start thinking about your design.  That’s too much work to put inside a thing that looks like a field access.  Give your users a fighting chance to understand where their costs are and let them query for a batch of results, probably asynchronously and then access them quickly when they arrive.  That’s going to be a successful pattern.

It goes without saying that under these conditions, the flexibility to version/replace/subtype virtual-call properties is actually illusory.  If you were to try to do something new and costly, or even just very different in a subtype you would likely cause all manner of problems for callers.  So while you do get to change things a somewhat, you cannot and must not, use that flexibility to access new and different subsystems or the like inside of a method that is supposed to be as small as a getter.  You are necessarily very constrained.

When I consider all of this I arrive squarely at the conclusion that more fields and fewer properties would be better.  Don’t hide real work inside a property and don’t use them as a synchronization tool.  Once you decide that you need a fetch/read pattern you soon find that that reading thing can be very simple/fast indeed and that perhaps fields were just fine after all.

Something to think about anyway. 

19 Dec 2011, 14:27:00   Source: Performance Guidelines for Properties   Tags: Performance

Parallel Programming: The Past, Present and Future of Parallelizing .NET Applications

In the world of multi-core and manycore everywhere, parallelism is now something every developer must at least consider, and something that the millions of developers that use managed languages must be able to take advantage of. Stephen Toub shows how parallelism is evolving in .NET.
28 Jul 2011, 19:00:00   Source: Parallel Programming: The Past, Present and Future of...   Tags: Performance