Really interesting stuff! Can't wait for more benchmarks :-)

Some more benchmarks (but with more iterations), using the same set-up...

Comparison of "native" methods and "dynamic" methods

These functions do exactly the same thing, but with startingly different results:

CurrentModel.ChildrenAsList.Count; 1 millisecond

Model.Children.Count(); 21 milliseconds

CurrentModel.GetChildrenAsList.Items.Count; 16 milliseconds

So you can see there is quiet an overhead in using "dynamic" methods compared to "native" DynamicNode methods.

And if we use Descendants() instead of Children (even when there is only 1 level of children) we get:

Model.Descendants().Count();26 milliseconds

So it seems that we should avoid using deep traversal methods like Ancestors() and Descendants() when we only need Child or Parent nodes.

Up() vs Parent

Model.Parent.Descendants().Count(); 27 milliseconds

Model.Up().Descendants().Count(); 29 milliseconds

Model.Up().Down().Up().Down().Up().Descendants().Count(); 30 milliseconds

Model.Ancestors().First().Descendants().Count(); 371 milliseconds

So we can see that there is little difference, and the penalty for going Up() and Down() is negligible. However, using Ancestors() can give quite a hit (which is understandable as it can potentialy traverse much deeper).

Ordering Results

Model.AncestorOrSelf().DescendantsOrSelf().OrderBy("id").Count(); 38 milliseconds

Model.AncestorOrSelf().DescendantsOrSelf().OrderBy("id desc").Count(); 38 milliseconds

So order direction makes no discernible difference, as you would expect. But splitting the OrderBy clause up does...

Model.AncestorOrSelf().DescendantsOrSelf().
OrderBy("Level, CreateDate").Count(); 64 milliseconds

Model.AncestorOrSelf().DescendantsOrSelf().
OrderBy("Level").OrderBy("CreateDate").Count(); 46 milliseconds

However, not sure if the above give the same ordered results and are directly comparable? Anyone?

Model.AncestorOrSelf().DescendantsOrSelf()
.Where("id > -1 && id < 1100").Count(); 39 milliseconds

Model.AncestorOrSelf().DescendantsOrSelf()
.Where("id > -1").Where("id < 1100").Count(); 40 milliseconds

Splitting and ANDed "where" clause into two doesn't seem to matter, which is what I'd expect.

Awesome! Would be interesting to actually package this up and we could use it to trace calls and see if we can improve performance. So the site along with a good range of DynamicNode calls could end up and a performance matrix. Game?

My basic benchmark Macro was just this:

@inherits umbraco.MacroEngines.DynamicNodeContext
@using System.Diagnostics;

@{
    long millisecs = 0;
    int samples = 10;
    int iterations = 5;
    int count = 0;

    for (int i = 0; i < samples; i++)
    {
        TimeSpan elapsed = Benchmark(iterations, out count);

        <h1>Time: @elapsed.Duration().Milliseconds millseconds</h1>

        millisecs += elapsed.Duration().Milliseconds;
    }

    long average = millisecs / iterations;

    <h2>Average: @average milliseconds to count @count nodes @iterations times</h2>
}

@functions
{
    TimeSpan Benchmark(int iterations, out int count)
    {
        count = 0;

        Stopwatch stopwatch = new Stopwatch();

        stopwatch.Start();

        for (int i = 0; i < iterations; i++)
        {
            count = Model.AncestorOrSelf().DescendantsOrSelf().Count();
        }

        stopwatch.Stop();

        return stopwatch.Elapsed.Duration();
    }
}

It really could do with a way of passing in the dynamic expression to the benchmark method, but I'm not clever enough to figure out how. Maybe Gareth can help? :)

is working on a reply...