Performance

Obsessive Coding, optimal string Reverse...

Scott Galloway — Mon, 04 Feb 2008 17:00:41 GMT

I love this type of thing, a whole post on optimal string reverse algorithms. I always love this sort of thing, learning huge amounts of detail about fundamental operations (sort of, umm when do you ever reverse strings?). Actually looking at Justin Rogers' blog he has lots of great performance posts...

Why do so many people mess up Singletons?

Scott Galloway — Mon, 28 Jan 2008 00:47:55 GMT

I've written about this a few times now (use the search thingy to find where) but I'm still surprised how many people mess up the Singleton pattern.

For instance take:

if (blogSettingsSingleton == null)
                {
                    blogSettingsSingleton = new BlogSettings();
                }
                return blogSettingsSingleton;

Looks ok, right? But this is a classic poor pattern when dealing with multi-threaded apps. Why? Look at the initial 'if' statement, and think what happens if multiple treads hit this at the same time...one thread could be in the process of creating this object whilst the others are evaluating the condition...

If you're using Singletons PLEASE read this article. The singleton pattern article from Wikipedia has the following excellent implementation of a singleton:

/// <summary>
/// Class implements singleton pattern.
/// </summary>
public class Singleton
{
        // Private constructor to avoid other instantiation
        // This must be present otherwise the compiler provide 
        // a default public constructor
        private Singleton()
        {
        }
 
        /// <summary>
        /// Return an instance of <see cref="Singleton"/>
        /// </summary>
        public static Singleton Instance
        {
            get
            {
                /// An instance of Singleton wont be created until the very first 
                /// call to the sealed class. This a CLR optimization that ensure that
                /// we have properly lazy-loading singleton. 
                return SingletonCreator.CreatorInstance;
            }
        }
 
        /// <summary>
        /// Sealed class to avoid any heritage from this helper class
        /// </summary>
        private sealed class SingletonCreator
        {
          // Retrieve a single instance of a Singleton
          private static readonly Singleton _instance = new Singleton();
 
          /// <summary>
          /// Return an instance of the class <see cref="Singleton"/>
          /// </summary>
          public static Singleton CreatorInstance
          {
            get { return _instance; }
          }
        }
}

This is a lazy-initializing, thread safe singleton...does sacrifice *some* performance (see the earlier article for details of this) but it is FAR safer than the original I showed...

Oh, and one last thing...are you REALLY sure you need a Singleton? One horrible pattern I've seen is code is using Singletons to access database connections...this is VERY RARELY required and sacrifices a lot of the benefits which modern databases offer for concurrent access.

UPDATE: Umm...realized that I don't explain what a 'Singleton' is...essentially it's a pattern which limits the access of an object to a single caller at a time. Common uses for Singletons could be accessing files on a file-system where you really want to make sure that only one thread has access at one time. Oh, and to make things even more complicated you'd more commonly want to use a ReaderWriterLock in this scenario to allow many readers or a single writer...only of course you wouldn't...told you it was complicated! Oh, and to further complicate matters in VS2008 and above you'd probably want ReaderWriterLockSlim!

Really nice article on .NET Data Access

Blog Author — Thu, 07 Apr 2005 17:37:00 GMT

Steven Smith has a great little article on ASPAllicance on comparing performance and methods of performing data access in .NET applications. Some really interesting techniques there, I especially like the IDataReader delegate example, a really nice solution to passing IDataReaders between layers in an app…

Nested repeaters - new article on Codeproject and why you shouldn't do it that way!

Blog Author — Sat, 21 Feb 2004 19:15:00 GMT

Just been reading this article on Codeproject.com...hmm...I have a few issues with how he does things:

DataBinder.Eval - I have what is becoming an obsession about this now - there's just NO NEED for this in most cases, it sucks in terms of performance (you can typically lose about 20% compared to the stongly typed method. I've posted a couple of times about this here and here.
OnItemDataBound - now, I've yet to do a benchmark comparing to member methods (just reminded myself actually, I might do one this weekend). I use to use this method all the time for nested repeaters until I saw the light and moved on to Member Methods - which as well as feeling a lot 'cleaner' than the event based approach - I feel will be significantly faster - since it avoids the overhead of events and casting required for the ItemDataBound approach.

So anyway, I will put my money where my mouth is and finally get down to writing an article about the relative merits of these approaches...but the bits I've mentioned above are based on a LOT of uses in real applications - believe me I make these suggestions not on a whim but based on a lot of trial and error!

Web Service Compression - really nice implementation of a Web Service Extension (with sample)

Blog Author — Sat, 24 Jan 2004 22:32:00 GMT

I've posted about this topic a few times, it's really nice to see that someone has finally given a practical, free method of doing this. This implementation uses WS-E to do this, meaning that you add an attirbute to both the client and server portions of your web service - and there you have it, a compressed SOAP message!
If you're using Web Services and transmitting any non-trivial amount of Data, I really do recommend that you use compression on the SOAP message (especially if you're sending DataSets, those buggers are huge when serialized - of course you can minimize them in a different way), this is a very simple, intelligent approach to this problem, it can actually make Web Services practical where they weren't before (as transmission latency can actually preclude their use in some circumstances).
Anyway, good job Glav!

UPDATE: Just found this article on DotNetJunkies - which seems to offer HTTP 1.1 compression for web services - yet to try it out (looking at the date it's possible it would only work for .NET 1.0 - but I'll give it a try and report the results!)

Another article in the offing...hopefully...if I get round to it...Member methods versus OnItemDataBound for nested Data List controls

Blog Author — Thu, 22 Jan 2004 19:19:00 GMT

A very common question in the ASP.NET Forumsis "How do I nest one Repeater (or DataList or DataGrid) inside of another?"; well, my usual stock answer used to be to use the OnItemDataBound event then use a FindControl() to find the Repeater inside the template and set it's datasource to the child view - then just DataBind...Recently though, I've gone against this - based in part on a bit in a book by Farhan Muhammad and Matt Milner (can't find the link to the exact book, but this one is pretty useful too), essentially, it involves using a member method. So, instead of hooking up the event you simply specify the DataSource of the Child Repeater as follows (for example)
<asp:Repeater id=FormatsRepeater DataSource="<%# GetFormats(Container.DataItem)%>" Runat="Server">
, along with the rest of the templates etc for the child repeater. Then, in code (the codebehind normally), you simply do this:

public DataView GetFormats(object DataItem)
{
DataRowView di = DataItem as DataRowView;
if(di!=null)
return di.CreateChildView("JobCount");
else
return null;
}

Hmm..BlogJet isn't great at letting me modify HTML - I'll sort this later...anyway, as you can see, very simple code (incidentally, should mention, I'm using a DataSet with a DataRelation called JobCount). What's the upshot of all of this...well, the Member Method version, as well as (IMHO) being much easier to write than the ItemDataBound version - is also MUCH faster - in some tests, twice as fast! Anyway, I will hopefully write a bigger piece on this with some stats to prove my point - if I get round to it :-)

More on my Load Testing fun...

Blog Author — Wed, 21 Jan 2004 09:57:00 GMT

Well, still at it (20 hours after starting - yes, the time on this post is correct!). Really fustrating mostly, but one of those times coding where hours and hours of pain (literally in this case - flu and splitting headaches were involved) were followed by a sudden dawning then a solution.
Well, I've learnt more about Load Testing and SQL Server performance today than I had in the previous 2 years, lessons I've learnt:

SQL Profiler is god's own tool (not in any nasty sordid way, in a good way) - use it, love it! If you're running a load test, run Sql profiler at the same time...then look at the results, taking special note of reads and duration of queries...then...
Use SQL Query Analyzer's 'show execution plan' option, look at the little graph carefully, looking for places where lots of non-indexed table scans are happening / a whole lot of work is going on where you don't expect it!#

It turned out that my problem was to do with a trigger firing on inserts, this updated a stats table which locked my main table - resulting in a bad Deadlock...as long as I had free connections it was fine, but the connections following the insert which queried the same data were getting hung because of the trigger's lock - so the number of connections racked up, eventually causing timeouts and other horridness...

Incidentally, I came across the rudest, most unhelpful Sales rep on the planet today (my opinion only!), a certain load testing tool company (the No.1 in the world apparently - god knows why!), I needed an eval license to do a quick run through of the load testing script my client was using - so I applied for an eval license from the website, downloaded and installed the tool - so far so good! Now, if this product was good enough, my company would probably have sprung for a license - problem is that they 'don't offer eval licenses in Europe' - implication was that I'd use it to rip them off. Alternative, spend an afternoon with their sales guy or spend $10000 on a product which I've never used (an afternoon would mean rouchly £5000 lost earnings for my company). My alternative was to use the free eval of another company's tool (won't mention the name yet in case I hate it) - so the first company have just lost a potential sale.

If you offer an eval download - especially one that requires you to install the software before you can even apply for a liocense - make damn sure you mention that there's not actually one available!