CPU utilization too high with dll v4.0.X

[Nassim Farhat]

Hi,

We have a Grid grouping that get's it values updated very frequently (on the same column of the grid), all work perfectly well when the row elements have no childs. But when it does, it get so slow that I lose control over the UI (CPU at it's top).

I've included two screenshots, one fast and one slow with a callstack from dottrace. I've underline the method that makes the biggest change when drawing the grid on a list changed event : Syncfusion.Windows.Forms.Grid.GridPaint.DrawClientRowCol() which calls Syncfusion.Windows.Forms.Grid.GridPaint.InternalDrawCell() and so on for Spanned Cell.

It seem like they are so much more thing to do internally just to update a child column value. Note that we use a binding list for the childs of an element. The childs list changed event is registered in Syncfusion.Grouping.Group.SourceList:

bindingList.ListChanged += new ListChangedEventHandler(bindingList_ListChanged);

Thanks,

Charles

Attachment: rendering_49e2c33_ad3f24f3.zip

[Neelakandan Kannan]

Hi Charles,

Thank you for your interest in Syncfusion products.

Query Frequent update on GridGroupingControl	Suggestion-1: The reported scenario can be resolved by using UseDefaultsForFasterDrawing property as true. The entire GDI will be redrawn when this property is enabled. Please refer the below code: gridGroupingControl1.UseDefaultsForFasterDrawing = true; Please refer the below UG link: http://help.syncfusion.com/ug/windows%20forms/default.htm#!Documents/highfrequencyupdates.htm
	Suggestion-2: IF you want to optimize the engine , you can use the AllowOptimizations property. Engine optimizations can be enabled by setting AllowOptimizations to some value other than None. Please refer the below code: GridEngine schema = new GridEngine(); schema.InvalidateAllWhenListChanged = false; schema.AllowedOptimizations = EngineOptimizations.All; schema.CounterLogic = EngineCounters.YAmount; Please refer the below UG link: http://help.syncfusion.com/ug/windows%20forms/default.htm#!Documents/memoryperformanceeng.htm
	Suggestion-3: The GridGroupingControl provides easier way to repaint all the rows once it has been updated. You can set TableDirty = true and the engine won't try to keep anything in synchronization at that time. Please refer the below UG link: http://help.syncfusion.com/ug/windows%20forms/default.htm#!documents/listchangedperforman.htm

 Please let me know if you have any concerns.

 Regards,

 Neelakandan

[Neelakandan Kannan]

Hi Charles,

 

Thank you for your interest in Syncfusion products.

 

Query Frequent update on GridGroupingControl	Suggestion-1:   The reported scenario can be resolved by using UseDefaultsForFasterDrawing property as true. The entire GDI will be redrawn when this property is enabled.   Please refer the below code:   gridGroupingControl1.UseDefaultsForFasterDrawing = true;   Please refer the below UG link:   http://help.syncfusion.com/ug/windows%20forms/default.htm#!Documents/highfrequencyupdates.htm
	Suggestion-2:   IF you want to optimize the engine , you can use the AllowOptimizations property. Engine optimizations can be enabled by setting AllowOptimizations to some value other than None.   Please refer the below code: GridEngine schema = new GridEngine(); schema.InvalidateAllWhenListChanged = false; schema.AllowedOptimizations = EngineOptimizations.All; schema.CounterLogic = EngineCounters.YAmount; Please refer the below UG link: http://help.syncfusion.com/ug/windows%20forms/default.htm#!Documents/memoryperformanceeng.htm
	Suggestion-3:   The GridGroupingControl provides easier way to repaint all the rows once it has been updated. You can set TableDirty = true and the engine won't try to keep anything in synchronization at that time.   Please refer the below UG link:   http://help.syncfusion.com/ug/windows%20forms/default.htm#!documents/listchangedperforman.htm

 

Please let me know if you have any concerns.

 

Regards,

Neelakandan

[Nassim Farhat]

Hi,

We have already tried the first and second suggestion, but they do not affect the performance when drawing child element.

I've tried to set the Table.TableDirty property to true for the main table each of the underlying one (ChildTable.cs via EngineTable.TableDirty property), but it keep getting set back to false in Table.cs.

I'm I missing something?

Note: We have no problem on the main table, but for every nested child table it's very very slow.

[Neelakandan Kannan]

Hi Charles,

 

Thank you for your update.

 

The reported child table does not drawn properly can be resolved by enabling the table dirty property for every child table when RecordExpanded. Please make use of below code,

 

void gridGroupingControl1_RecordExpanded(object sender, RecordEventArgs e)

{

e.Record.Engine.Table.TableDirty = true;

}

}

 

Note:

If you still have an issue, Is there any possible way for you to provide us with a sample that shows this issue? It will be easier for us to have a closer look into the problem and resolve it.

 

Please let me know if you have any concerns.

 

Regards,

Neelakandan

[Nassim Farhat]

Hi,

Setting TableDirty did not really help, it's always set back to false. However, I've managed to optimize our code by implementing a couple of method of your object (see attached code.txt file). It's very simple (and ugly), I just avoid calling the WndProc for GridGroupingControl or bindingList_ListChanged for Table too often. Anyway the user does not see the difference since the value change very fast.

My first optmization was only with CoreGridTable class, since I notice that the bindingList_ListChanged triggered engine synchronisation and that 80% of the time was taken by this synchronisation (see before.png). The before2.png illustrate how much time the WM_PAINT is taking. At first this optimization did not do anything since strangely the WndProc with the WM_PAINT message was now taking all the processing power (up to 80% instead of the original 5% of before2.png). So I added the the CoreGridTableControl class to control this event. This ended up saving 40%, and now 40% of the time is in that WM_PAINT (see after.png).

My question is why does the paint event takes all the place and slow down everything. Normally I would expect my first optimization to work without the second one.

Thanks,

Charles

Attachment: dictionnary_8b669cfe.zip

[Neelakandan Kannan]

Hi Charles,

 

Thank you for your update.

 

We analyzed your reported scenario at our end. The method you are handling to reduce the CPU utilization is better method. The Painting issue may be occurred if nested table or child table does not properly handled for insertion. Meanwhile, we request you to use UseDefaulstForFasterDrawing property. It is used to improve handling of ListChanged events and scrolling through grid. If you still have an issue, Please try to replicate your scenario in below sample. It will help us to provide you better solution as soon as possible.

 

Please refer the below code:

               

this.gridGroupingControl1.UseDefaultsForFasterDrawing = true;

 

Please let me know if you have any concerns.

 

Regards,

Neelakandan

 

Attachment: Uniform_Child_List_Demo_220287a5.zip