How to kill Sitecore whilst getting the languages for an item

I was reviewing a solution (not developed by Pentia) for a customer as they were concerned about the performance and stability of their site.

It didn’t take me long to find the following bit of code which calls the SQL server to find the languages for a given item:


I was shocked that anyone would not use the Languages property on the Item class, which would have replaced the entire function.

I think in all my years of Sitecore development this is the worst bit of code I have ever seen, it shows  a complete lack of respect for the API and if  the site was upgraded it is possible that the database schema could change and therefore the code would break!

On average the SQL query took 400mS (which is quite slow, but then again the SQL server was getting hit by 4 front end servers for every request).

The same call to the Item.languages took 0.1mS, this simple change made every request 400mS quicker and reduced the load on the SQL server considerably.

4 thoughts on “How to kill Sitecore whilst getting the languages for an item

  1. Mark Cassidy

    Ugh, I feel your pain. I come across “gems” like this from time to time as well. How about (written from memory – and this is probably nicer than the actual code):

    public string GetSitecoreFieldValue(Item item, string fieldName)
    Database master = Sitecore.Configuration.GetDatabase(“master”);
    Item theItem = master.GetItem(item.Paths.FullPath);
    Field field = theItem.Fields[fieldName];
    if (field != null)
    return field.Value;
    return “”;

  2. Nat

    Tbf, I think another gem I have come across was (pseudo-code)

    public string GetTranslation(string key)
    Item dictionaryRoot = Sitecore.Context.Database.GetItem(“{path to dictionary root}”);
    foreach(Item child in dictionaryRoot.GetChildren())
    if(child[“key”] == key)
    return child[“value”];
    return String.Empty;

    Not only was is wasteful on calls, the dictionary unfortunately was added to until it got > 500 items. The compounded by the fact the method was called for every text string on the page (some 60 – 70 calls). It was bad in production, but in the page editor, without the caching, it was horrendous.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.