Accessing Range.Start in Loop Improves Performance Of Comparer

Question

I'm experiencing a very strange issue. So, the background is that we have a mapping between Word ContentControl and a custom object we use to store some information related to the content inside that control. We use a SortedList<ContentControl, OurCustomObject> to maintain this mapping. The SortedList part is useful to be able to find the next/previous content control, as well as to be able to quickly access the object associated with a content control.

To set this up, we do something like the following:

var dictOfObjs = Globals.ThisAddIn.Application.ActiveDocument.ContentControls
    .Cast<ContentControl>()
    .ToDictionary(key => key, elem => new OurCustomObject(elem));
var comparer = Comparer<ContentControl>
    .Create((x, y) => x.Range.Start.CompareTo(y.Range.Start));
var list = new SortedList<ContentControl, OurCustomObject>(dictOfObjs, storedcomparer);

This seemed to work pretty well, but I recently tried it on a document with ~5000 content controls, and it slowed to an absolute crawl (3+ minutes to instantiate the SortedList).

So that's strange enough, but even more strangeness was yet to come. I added some logging to figure out what was going on, and found that logging the start of each ContentControl before using them in the list sped it up by a factor of ~60. (Yes, ADDING logging sped it up!). Here is the much faster code:

var dictOfObjs = Globals.ThisAddIn.Application.ActiveDocument.ContentControls
    .Cast<ContentControl>()
    .ToDictionary(key => key, elem => new OurCustomObject(elem));

foreach (var pair in dictOfObjs)
{
    _logger.Debug("Start: " + pair.Key.Range.Start);
}

var comparer = Comparer<ContentControl>
    .Create((x, y) => x.Range.Start.CompareTo(y.Range.Start));
var list = new SortedList<ContentControl, OurCustomObject>(dictOfObjs, storedcomparer);

The constructor for SortedList calls Array.Sort<TKey, TValue>(keys, values, comparer); on the keys and values of the dictionary. I can't figure out why accessing the Range objects in a loop beforehand would speed it up. Maybe something to do with the order in which they are accessed? The foreach loop will access them in the order they appear in the document, while Array.Sort will hop around all over..

Edit: When I say SortedList, I mean System.Collections.Generic.SortedList<TKey, TValue>. Here is the code for the constructor I'm using:

public SortedList(IDictionary<TKey, TValue> dictionary, IComparer<TKey> comparer) 
    : this((dictionary != null ? dictionary.Count : 0), comparer) {
    if (dictionary==null)
        ThrowHelper.ThrowArgumentNullException(ExceptionArgument.dictionary);

    dictionary.Keys.CopyTo(keys, 0);
    dictionary.Values.CopyTo(values, 0);
    Array.Sort<TKey, TValue>(keys, values, comparer);
    _size = dictionary.Count;            
}

Answer 1

Besides your performance issue, I think your solution (unless the document is in fact a static document) will fail over time. Range.Start locations tend to be shifting depending on adding/removing content from your document.

To prove this, add the following little macro and run it from VBA:

Sub testccstart()

    Dim cc As ContentControl
    Set cc = ActiveDocument.ContentControls.Add(wdContentControlRichText)

    MsgBox cc.Range.Start

    ActiveDocument.Range(0).InsertBefore "Blablabla"

    MsgBox cc.Range.Start

End Sub

You'll notice the Range.Start of the Content Control shifted from 1 to 10 the minute you entered the text at the start of the document. So all edits in your document require you to reload the Range.Start based lists.

The answer to your question though is that by adding the logging your triggered some what they call 'Lazy Loading' (loading only things when actually accessed). There are all sorts of optimizations within Office that are not always clear (for instance, accessing Excel ranges is often much faster using arrays).

I tested a bit and wonder if this might be a solution for you:

 var dictOfObjs = document.ContentControls
                        .Cast<ContentControl>()
                        .ToDictionary(key => key.Range.Start, elem => new OurCustomObject(elem));

 var comparer = Comparer<int>.Create((x, y) => x.CompareTo(y));

 var list = new SortedList<int, OurCustomObject>(dictOfObjs, comparer);

Instead of using the Content Control as Key (I guess you store the Content Control already in OurCustomObject?) assuming the Content Controls each have a unique start position use the start position as Key, this brought my processing of 1600 items back from 48 to 5 seconds ...