Dynamic property performance improvements

I won't give you a background on dynamic properties here. If you don't know about them, this blog post will probably not make much sense to you anyway.

The bad

Dynamic properties in EPiServer CMS has a bad reputation for killing performance. The actual problem is not really when accessing the properties, it is an old design decision that optimizes the "read dynamic property from cache" part. You could probably see this as an effect of a premature optimization where the big picture was not clear before the decision was made.

Getting a dynamic property from cache is extremely fast - yes you do have an overhead compared to "regular" properties, but comparing this to the overall execution time for a page it is close to negligible.

Why is it a bad thing to optimize heavily to what you would regard as the most common use-case for dynamic properties (reading them for a page)?

Well, in order for the "read from cache" to be as fast as possible, we store a short-circuited tree structure in the cache with nodes directly linking only to pages where we have an actual dynamic property definition. This tree needs quite a lot of work to be setup and most of this work is done in the database procedure that gets the data. I e when the cached information is flushed, performance gets bad.

Since we store a partial representation of the tree structure it needs to be flushed as soon as you move or delete a page and that is the core of the dynamic property performance problems.

The good

It's fixed. Yes, it is really fixed now. We no longer flush the cache on move, the actual operation of reading dynamic properties from the database is fast and you should no longer see any bad side-effects of using dynamic properties.

We de-optimized the "read from cache" scenario and that allowed us to simplify the code and data structures. Instead of doing a quick lookup in a hash table, we do a standard "follow the parent chain" loop in order to find pages with dynamic property definitions. This makes the read access for dynamic properties slower than it used to be, but it is still in the <1% range of total page execution time.

The nice side-effect

There is a related optimization that was done, which you may want to use in your code. The default DataFactory.GetPage() API will use the default LanguageSelector implementation, which contains quite a lot of logic for dealing with language falllbacks etc. In some cases you don't really care about the language specific information, in the dynamic property case we just want to iterate over the the parent chain. We therefore have a new NullLanguageSelector which simply uses whatever language is present in the returned PageData object.

To use it yourself you can write code like this:

var page = DataFactory.Instance.GetPage(pageLink, NullLanguageSelector.Instance);

If you make a lot of GetPage calls that uses non-language specific information you may see a fair performance improvement in the range of 5 - 15% for this specfic API.

When can I see the new dynamic property goodness?

In EPiServer CMS 6 R2.