grid, styles, and performance

[damien morton]

Ive been profiling some data bound grid code I wrote, and have found that scrolling performance is quite slow - scrolling a 50 row window over a 1000 row by 30 column grid takes about 5 seconds from top to bottom.

About 10% of that time is taken up by acessing the bata bound backing store, while 40% is syncfusion draw/paint code and a further 40% is taken up by syncfusion code to do with processing/accessing/inheriting styles.

I want to increase the performance of my grid, and Im thinking that eliminating the style inheritance portion of the code would be a good way to do that.

My grid requires only one style for row headers, one style for column headers, and one style for cells. No style inheritance is necessary.

Currently, my grid has the 4 default (normal, standard, rowstyle columnstyle) styles attached to it. Im thinking that eliminating those styles would be a good start.

Im not really clear on how syncfusion handles the inheritance of styles. Ideally, what Id want to do is intercept whatever code is responsible for building/merging/composing styles, and to return one of several constant, flat, non-inheriting styles, depending on what is being currently rendered.

Ive looked at the PrepareStyleInfo and QueryCellInfo methods, but it seems to me that the stye inhertiance mechanism is already in play by the time we get to those calls.

Is there somewhere earlier in the chain of events that would be worth looking at?

[Administrator]

The 40/40 seems about right. But the style architecture is such an important piece of the grid that we see that as a good compromise (and we actually still scroll faster than other grids ... had to mention that here).

There are no events that are raised earlier. What you would would have to replace is the GridVolatileData class. That is where a identity object is attached to the GridStyleInfo objects and the identity object handles the inheritance mechanism for each style object. You could here provide your own style info identity object/class that does not return base styles. In 1.6 the VolatileData property is internal, so you can't replace that, but we can make it public if that is usefull for special situations.

If you want to go that road please open a support incident and we can give you access to a 2.0.x version where we can make that property public.

Stefan

[damien morton]

Thanks for the tip - I will see about getting hold of the 2.0.x branch - when is that scheduled for actual release?

As for the grid being slow - my boss tells me that syncfusion is indeed faster than other grids - Im just trying to maximise the performance of the grid we are using by specializing it to our needs.

I spent some time looking more deeply into the style architecture last night, and I find it to be an incredibly flexible system.

One thought that I had while looking at the archiecture was that it might be possible to use CodeDOM to dynamically build and compile style types that actually inherit from each other. This would hugely speed up the property inheritance mechanism.

Also, if you were able to specify which properties should be inherited, and which properties could be dynamically altered (in instances of that type), this would help the compilation process a lot.

Just a few thoughts.

Thanks for the tip about GrdiVolatileData - Ill take a closer look at this.

> The 40/40 seems about right. But the style architecture is such an important piece of the grid that we see that as a good compromise (and we actually still scroll faster than other grids ... had to mention that here).
>
> There are no events that are raised earlier. What you would would have to replace is the GridVolatileData class. That is where a identity object is attached to the GridStyleInfo objects and the identity object handles the inheritance mechanism for each style object. You could here provide your own style info identity object/class that does not return base styles. In 1.6 the VolatileData property is internal, so you can't replace that, but we can make it public if that is usefull for special situations.
>
> If you want to go that road please open a support incident and we can give you access to a 2.0.x version where we can make that property public.
>
> Stefan

[Administrator]

Damien,

I'll gonna take a closer look at the suggestion to specify which properties should be inherited. That makes sense for certain properties that don't need such inheritance.

Thanks,
Stefan