Performance issue loading window with ribbon

The only time we've ever heard of an assembly taking that long to load is if you are using code-signed assemblies since .NET does have a bug in it that can prevent them from loading fast and can introduce delays.  Are you using the regular or code-signed versions of our assemblies?  The code-signed ones are distributed in the CodeSigned folder, and the related slowness issue is described more here.

Our main ribbon features demo has a number of tabs and loads up pretty fast.  If you are not using code signed assemblies, then you'd need to use a performance profiler tool to determine exactly what is taking most of the time.  I'd recommend a tool like dotTrace.  Those kinds of profilers will tell you which code paths are taking up all the time.

We are not using the code-signed versions.

With the VS 2010 analyser i get this information.
I start the application and open/close the window where the ribbonbar is inside 35 times.

The System.Windows.Application.LoadComponent is using 45,8% of the cpu time

MainRibbonBar.Xaml.vb

Public Sub New()
'this call is required ....
InitializeComponent()        ==> 39,8%

is used up by loading the ribbon.
In my situation the ribbonbar is a separate ribbon (usercontrol), that is loaded into a ribbonwindow.

<ribbon:RibbonWindow x:Class="PageDesignWindow"
xmlns:commands="clr-namespace:MyNameSpace.Ribbons">

<DockPanel >

<commands:MainRibbonBar x:Name="MainRibbonBarControl" DockPanel.Dock="Top"></commands:MainRibbonBar>

'<other controls inside the dockpanel....>

</DockPanel>

I started another analyser which calculcates the calls for each function and the time used.
The first showdialog is the time starting the main window (which also has the ribbon), but also other functions).

The second showdialog is the separate window which was started by me 7 times.
This are the most expensive calls made by the system during runtime, The next item in line is about 3 seconds. So these are the most expensive ones in the whole application.

System.Windows.Window.ShowDialog()                                                             1 call              10.121 ms

System.Windows.Window.ShowDialog()                                                             7 calls           19.354 ms

System.Windows.Application.LoadComponent(object,class System.Uri)            1134 calls       12.343 ms

System.Windows.Application.LoadComponent(object,class System.Uri)            1303 calls       10.010 ms

Hi Arthur,

Does our Sample Browser's main Ribbon demo load up fast for you?

From your profiling, if you don't see that the methods in the Ribbon source code are directly contributing to the slowdowns then there's not much we can do on our end.  Perhaps you just have too many elements loaded in your case.

You said you have 20 contextual tabs in your Ribbon.  What if you broke those out into separate classes (not UserControls but classes that directly inherit ContextualTabGroup - you can still do XAML with that) and then just loaded them on demand, as needed?  That would significantly reduce your overall element count and may help a lot.

If you have a look at the Ribbonwindow with Docking you will notice a lag between the click and the actual window being shown.

There is about a 1 second lag. (if I start MS word, the windows is there immediately)
I think the loading message... is there in the sample demo because you know there is a lag while opening a window.

but your examples do not have any bindings, only fill in the first 3 tabs, and the rest is empty.

So there is no real example as the world would use it.

The only thing i can do is made a complete copy of my projects and try to remove bindings/tabs to see where the lag comes from.
What you mention about the conceptual tabs is maybe a solution if i can find out where the lag is located.

On fast machines it is workable, but laptops which often do not have such as powerfull video card have problems loading these windows and become unworkable.

Hi,

I profiled my application for load/startup using VS2010 profiler and observed it is showing following results. I'm using 64 bit OS

1. 19.2 % - ActiproSoftware.Windows.Controls.Ribbon.RibbonWindow.OnSourceInitialized
2. 10 % - ActiproSoftware.Windows.Controls.Ribbon.RibbonWindow.MeasureOverride
3. 14.44 % - ActiproSoftware.Windows.Controls.Ribbon.Themes.RibbonClassicDictionary..ctor()

There are few more Actipro related fucntions but above one are most time consuming.

The total time usage after adding remaining function makes the figure close to 50%.

Thus 50% of time of my application load is being taken up by Actipro. I have few othe third party and WPF controls as well but they are not taking as much time.

Could you please let me know your views / suggestions on this?

We still have this problem, and a probvlem that opening and closing a actipro ribbon cost us 20Mb of memory each time.

We currently are not yet on the latest version so i do not know if this is solved.

Hi Piyush,

It sounds like you are on an older version too since all of the code you mention has since been rewritten.  For instance we now have new code that does the window chrome rendering (OnSourceInitialized) and theming is different in general.  Although for themes, we do define hundreds of brushes so perhaps that will take some time to load regardless.

Arthur, we aren't aware of any memory leaks at this time.  I know that we worked with you in the past on a couple memory issues and resolved them.  And remember, you need to use a real memory profiler (like from memprofiler.com) to detect leaks.  You can't trust task manager.

Observed one more issue in different scenario:

ActiproSoftwWare.Windows.Control.Ribbon.RibbonWindow.OnPropertyChanged – 60%

Could you please confirm - In latest builds have changes been done for this as well?

Hi Piyush,

We no longer have that method in RibbonWindow. 

However even when we did, the code in there was a simple if statement and would not have contributed to any performance issues.  The 60% you see is probably just what is happening in the base.OnPropertyChanged call from that method.