Performance Woes With Syncfusion Menus

[David B]

My application is using Syncfusion menus on the main application form. Unfortunately, whilst I love the appearance of the menus, the performance leaves a lot to be desired. Performance is priority #1, #2 and #3 at my company and the performance is a big problem. Profiling my main form''s InitializeComponent method which is over 3000 lines long, shows that just 3 lines!!! take over 50% of the time to execute. The lines are all to do with Syncfusion menus... this.m_mainFrameBarManager = new Syncfusion.Windows.Forms.Tools.XPMenus.MainFrameBarManager(this.components, this); this.m_mainFrameBarManager.Items.AddRange(new Syncfusion.Windows.Forms.Tools.XPMenus.BarItem[] { ... ((System.ComponentModel.ISupportInitialize)(this.m_mainFrameBarManager)).EndInit(); Seems there''s some stuff going off deep down in the bowels of the Syncfusion code that could be improved. Seeing "foreach" everywhere doesn''t fill me with much confidence that the code has been written with performance as a high priority. Aside from Syncfusion pulling up their socks, is there anything else (besides pre-jitting) that I can try?

[Ramesh Praveen]

Hi David,

This has been reported, frequently, as an issue with the menus by some of our customers.

Our dev. team has now decided to give this (instantiation and rendering performance of menus) top priority before the final 2.0 release (the first beta was announced last week) in a month or so. So, you can be assured of much better performance in our upcoming version.

We apologize for the inconvenience this might have caused you.

Regards,
Praveen Ramesh

[Ramesh Praveen]

Testing...

[David B]

Hi Praveen,

Syncfusion certainly has the look and feel we want, but we have recently been forced into a position where we are seriously (almost certainly) considering dropping Syncfusion altogether. Our product is in the QA/QC phase and besides general performance issues during runtime, our product startup time is unacceptably slow. We have determined that around 8 seconds of that startup time (or more than 1/2) is due to Syncfusion, Syncfusion dependencies (e.g., System.Xml) and slow constuction and initialization of Syncfusion components.

You say that this has become a focus for version 2.0 and I can only say that I hope this is truly the case. We really don''t want to drop Syncfusion; we have invested quite a bit of time into your products, but as it currently stands I doubt we can continue to use them.

Let''s hope that version 2.0 delivers the performance we need!

Thanks,
David B.

[Administrator]

David,

I understand the problem. We have already begun work on optimizing load-time for our menus. This will then defenitely be part of our next beta release before the end of this month.

If you could point me at anything else in particular that is performing poorly we will try to work on those as well.

We will keep you posted on this one.

Regards,
Praveen Ramesh

[Lucas J. Sain]

The comboBoxAdv works very poorly....

[Administrator]

Hi Lucas,

Can you elaborate on the problems you are experiencing with this control?

Thanks,
Daniel

[Lucas J. Sain]

I have reported this in the direct-trac. I think it has been reported as bug report: 137.

It has to to with the comboBoxAdv when assigning a DataSoruce to it is much more slower than the comboBoxBase.

regards
Lucas

[David B]

Other performance issues seem to be related to assembly loading. For starters Syncfusion assemblies seem to load slower than most (I''ve profiled it) but am not sure why they load slower. I''m getting about 400-500ms per assmebly on a cold startup. Secondly, startup time of a .Net app is related to working set and number of dependencies. To use Syncfusion you need to reference too many assemblies! Syncfusion.Grid, Syncfusion.Tools, Syncfusion.Shared, System.Xml, System.Design are all assemblies I see being pulled in by Syncfusion.

Why do you need a reference to Syncfusion.Grid, just to use a MainFrameBarManager? Why is System.Design being pulled in?

With the 5 assemblies I listed above I have to take almost a 3 second hit on cold startup, just to have a nice looking menu. We want our whole app up on screen in less than that. Then it takes 2 seconds to construct and initialize a MainFrameBarManager. :-(

I''d love to see you guys reduce your working set. We''d also love to have v2.0 out and ready and greased lightining fast and bug free by the end of this month, but we know that in the real world that won''t happen. Are you guys working 7 days/week on this? Even if you are we are using 1.6.1.8 in a product that is about to ship. V2.0 enhancements in reality probably won''t help us.

As I (and others in my company) see it, we have the following options:
1. Go with standard .Net menus, and drop the Syncfusion menues and docking manager.
2. Find another vendor (quickly). Even (dare I say it) ActiveX vendors are in the running.
3. Major code refactoring in our product to elminate dependencies on Syncfusion until after main form has been displayed. This is unlikely due to timeframe.
4. Get some urgent help from Syncfusion to improve performance of 1.6.1.8.

Is Syncfusion up to the challenge?

David B.

[Ramesh Praveen]

David,

Just an update on certain things we are working on for our 2.0 release that will greatly improve load time.

1) We will get rid off (or configure to delay load) certain assemblies (*.desing.dll, etc.).

2) We are contemplating a modules based approach where we chop our dlls into different modules which will get loaded only on demand.

3) Various performance related issues in our components, unrelated to loading.

You should then see a major improvement in performance in 2.0.

Also, based on our conversation outside this thread (via Howard), we are investigating on ways to help you improve performance with 1.6.*.

Regards,
Praveen Ramesh

[Thomas Zueger]

David,

We are developing an extensive application framework with .NET and we are using most of the Syncfusion components. One thing I can say is that the 2.0 version is mutch more faster than the 1.6 versions. We are also looking forward to get a more faster load behaviour than now. Faster would be better, but I can live with it at the moment.

Regards,
Thomas

[Sean Greer]

David,

What class of machine are you testing on? Processor, memory, OS, etc. Are you running under the debugger? How many bars and bar items do you have? Are you running against local assemblies or are they in the GAC? Have you thought about using NGEN (though some Microsofties say that the 1.x version creates it''s own issues)?

My main form has quite a few large controls, docking manager + 3 docked controls, main form bar manager, grids, etc. and the entire InitializeComponent is taking 1.2 seconds under the debugger. This is using 1.6.

I''ve been extremely impressed by the functionality and performance of the Syncfusion components. If you''ve found something that is better, I''d love to hear about it.

Sean

>Other performance issues seem to be related to assembly loading. For starters Syncfusion assemblies seem to load slower than most (I''ve profiled it) but am not sure why they load slower. I''m getting about 400-500ms per assmebly on a cold startup. Secondly, startup time of a .Net app is related to working set and number of dependencies. To use Syncfusion you need to reference too many assemblies! Syncfusion.Grid, Syncfusion.Tools, Syncfusion.Shared, System.Xml, System.Design are all assemblies I see being pulled in by Syncfusion.
>
>Why do you need a reference to Syncfusion.Grid, just to use a MainFrameBarManager? Why is System.Design being pulled in?
>
>With the 5 assemblies I listed above I have to take almost a 3 second hit on cold startup, just to have a nice looking menu. We want our whole app up on screen in less than that. Then it takes 2 seconds to construct and initialize a MainFrameBarManager. :-(
>
>I''d love to see you guys reduce your working set. We''d also love to have v2.0 out and ready and greased lightining fast and bug free by the end of this month, but we know that in the real world that won''t happen. Are you guys working 7 days/week on this? Even if you are we are using 1.6.1.8 in a product that is about to ship. V2.0 enhancements in reality probably won''t help us.
>
>As I (and others in my company) see it, we have the following options:
>1. Go with standard .Net menus, and drop the Syncfusion menues and docking manager.
>2. Find another vendor (quickly). Even (dare I say it) ActiveX vendors are in the running.
>3. Major code refactoring in our product to elminate dependencies on Syncfusion until after main form has been displayed. This is unlikely due to timeframe.
>4. Get some urgent help from Syncfusion to improve performance of 1.6.1.8.
>
>Is Syncfusion up to the challenge?
>
>David B.

[Administrator]

Hi Sean,

Have been testing with a Dell laptop, P4-2.4GHz, 1Gb RAM, Windows XP Professional, 32Mb nVidia GeForce 4.

Reason for testing with a laptop is the slower disk access times.

>> Are you running under the debugger? <<
Not when we ship the product of course! But, we have profiled times both under the debugger and out of it. I realize the effect on performance times using the debugger has. At the end of the day all times that matter have been clocked in release mode, external to the IDE.

>> How many bars and bar items do you have? <<
2 or 3 bars, with around 50 or so bar items.

>> Are you running against local assemblies or are they in the GAC? <<
Syncfusion assemblies are GAC''d assemblies.

>> Have you thought about using NGEN? <<
Yes. Initially tried and tested it and it made things worse. Later on we we tried it as a sanity check and it did actually help load times. Not sure how this result reversed itself, but we are loading assemblies slightly differently now.

>> I''ve been extremely impressed by the functionality and performance of the Syncfusion components. If you''ve found something that is better, I''d love to hear about it. <<
We too are definitely impressed with Syncfusion''s functionality, but can''t agree on performance I''m afraid. The docking manger seems to be OK on performance, thus indicating that loading times (with Ngen) are not so bad in the end, but if you are using menus/toolbars I''m sure you''ll notice a big performance problem in 1.6. That''s where your 1.6 second IntiialzeComponent method will blow out to 3 or 5 seconds!!! Even the 1.6 seconds under the debugger that you have is terribly bad.

For our app about to ship, we''ve regretfully had to pull menus and toolbars and use the plain looking .Net versions.

As for other vendors/options we looked a little bit, but nothing jumps out. I tested a major competitor of Syncfusion and performance of their components seemed to be even worse. Add to that that every single component lived in a different assembly which based on my profiling and talking to Microsoft would affect startup times since there''s an overhead for each assembly loaded, regardlesss of size.

After all of that I''m hopefully that v2.0 is going to help us out for our other applications we have in the pipeline.

Regards,
David.