CompletionSession performance

Comments (6)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Chris,

Can you make a simple sample project that shows this issue and email it to our support address so we can see if anything can be done to improve speed. I believe the ListBox's virtualization is already enabled, although we have some code to do some measurement of the text of items so that the width of the list snaps to the width of the longest item. That could be contributing to the slowness here.

Actipro Software Support

Posted 13 years ago by Kasper

Hi guys,

I wasn't sure whether to start a new thread or simply use this once, but I chose the latter, since it completely matches my problem. I have a brand new and pretty fast PC (Core i7-2600 @ 3.40 GHz, 16 GB RAM and the latest OCZ SSD as my system disk). I have almost 5.000 items in my list, which takes ~700 ms to show. If I leave out images on the items, I can shave that down to ~450 ms. Unfortunately, this is still too slow, especially when I compare it to the WinForms version, which is pretty much instant. Besides, the experience will likely be even slower for a lot of my customers, who doesn't have the same computer specifications.

I can see that the WinForms version could be optimized by caching the list of IntelliPromptMemberListItem's if they were the same from time to time, and then using the AddRange() method to add all the items to the list. However, with WPF, it seems that adding all the items is VERY fast (~1-3 ms), while the actual showing of the list is slow - the exact opposite as the WinForms version, as far as I can tell. Since I can't really do much about the Open() method being slow, I'm now asking for tips on how to optimize this, and if there are none, I would like to know if there are any internal optimizations planned for future releases. I know that 5.000 items is quite a bit, but I'm sure that you have customers with even greater needs :)

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Kasper,

Would you mind putting together a new simple sample project that shows the slowdown and email that over? We can use that as a basis to do tests on our end to see if we can improve performance anywhere.

One optimization (if you are using CommonImageSourceProvider for your item images) would be to reuse CommonImageSourceProvider instances as much as you can since they will cache the image, once it's loaded. That way perhaps you're only loading 10 images from the resources, instead of 5000.

Actipro Software Support

Posted 13 years ago by Kasper

Hi,

It's actually quite simple to re-produce, just add 5.000 items to the list and open it :). Here's the essential part from the sample I just wrote. If you need me to send it to you, just let me know, but it's nothing more than a Window, a SyntaxEditor with nothing changed and the following event:

private void Editor_DocumentTextChanged(object sender, ActiproSoftware.Windows.Controls.SyntaxEditor.EditorSnapshotChangedEventArgs e)
{
    if(e.IsTypedWordStart)
    {        
        CompletionSession session = new CompletionSession();
        for(int i = 0; i < 5000; i++)
            session.Items.Add(new CompletionItem("Identifier" + i, new CommonImageSourceProvider(CommonImage.ClassPublic)));
        Stopwatch sw = new Stopwatch();
        sw.Start();
        session.Open(Editor.ActiveView);
        this.Title = "Shown in " + sw.ElapsedMilliseconds + " ms";
    }
}

The following takes ~650 ms on my machine. If I leave out the image completely (session.Items.Add(new CompletionItem("Identifier" + i, null))), it takes around 450 ms. It doesn't appear that the big amount of items is a the main problem, because changing that loop to only 100 items still takes around ~80 ms to open. Let me know how the code performs on your machines and what your thoughts on this are :)

[Modified at 09/02/2011 04:17 PM]

Posted 13 years ago by Actipro Software Support - Cleveland, OH, USA

With your code, it took about 875ms on my machine to load. If I changed the code to reuse the same image provider instead of making one on each loop, that brought it down to 625ms. Not using an image provider was about the same, at 615ms. So that shows that using cached image providers attains similar performance to having no images.

We did some changes in our measuring logic so we only measure what we think are the longer items. In normal scenarios where there will be a large variation of item text lengths in the list, this will now perform many times (even 10x or more) better than the current code. In your particular sample, it doesn't help that much since the item texts are all IdentifierXXXX, which are roughly the same text length. But again, in normal usage you should see a dramatic improvement in speed.

These changes will be in 2011.2.

Actipro Software Support

Posted 13 years ago by Kasper

Cool, I'm looking very much forward to trying this out with my real use-case, where most of the items will be PHP functions, which can vary quite a bit in length :)

I was wondering though, if it could make sense to allow the developer to tell the SyntaxEditor which item is the longest? I usually have all my items in a list before I add them, so it would be pretty easy (and fast, I assume) to run through this list and find the longest item, which I could then tell SyntaxEditor about before adding the items. I'm not sure if this makes sense, or if it's at all usable in this situation, it's just a thought :)

[Modified at 09/06/2011 01:41 AM]

The latest build of this product (v24.1.2) was released 2 days ago, which was after the last post in this thread.

Comments (6)

Add Comment