All of our reports that are being generated are straight from the WinDataGrid and do not contain any images. The Export command uses the Grid and ISection parameters. We're noticing that the performance of this takes the majority of the processing time even with small (less than 1000 rows) reports. What can be done to improve the performance of the WinGridDocumentExporter?
Thank you
Clay Seifert
Hi Clay,
I'm not sure what you mean.
ClaySeifert said:We're noticing that the performance of this takes the majority of the processing time
The majority of what processing time?
How long is it taking to export less than 1000 rows?
How many columns do you have?
What version of the controls are you using?
Hey Mike
Sorry that I wasn't clear.
We're using NetAdvantage 10.2 and the reports have 15 columns and we average around 600 rows taking approximately 10 cpu seconds What I meant was the area that is handling the exporting is taking on average 80% of the total cpu time with the extraction of the data and loading it into the grid taking 20%. As the number of rows increases abovew 1000 rows, the percentage of time spent exporting increases dramatically.
I hope that this clears up my statement. What I'm looking for is suggestions and/or techniques to improve the export processing.
Thanks
Clay
Well --- you hit a grand slam in the bottom of the 9th with 2 outs!!!!
All of you suggestions were applied except for eliminating AutoFree. I needed to keep that because I do have columns that have different heights depending on the data. One change that I did implement (but not in the InitializeRow event) was the code that was in the RowExporting event. I included it within the BeginExport event along with the change for the code in the headerCellExporting event as follows:
e.Layout.Bands(0).Override.HeaderAppearance.BorderColor = Color.Black e.Layout.Bands(0).Override.HeaderAppearance.BackColor = Color.GreenYellow e.Layout.Bands(0).Override.RowAppearance.BackColor = Color.BlanchedAlmond e.Layout.Bands(0).Override.RowAlternateAppearance.BackColor = Color.WhiteSmoke
As a result, both of those events were eliminated and I had a 60%
performance improvement.
Attached you'll find a performance analysis before (ReportProcessor110419.vsp) and after
(ReportProcessor110420.vsp) the changes.
Appreciate your help on this.
It's hard to tell much from a single code file like this. I was really hoping more for a sample project that I could run and profile.
However, I took a look at the file and I see a couple of things you may be able to improve.
In the HeaderCellExporting event, you are setting the BorderColor and BackColor on the GridHeader object. Rather than setting this on each individual header, I think you could simply set this once inside the BeginExport event. The BeginExport event passed you a clone of the grid layout which you can modify without changing the on-screen grid. So you could simple set e.Layout.HeaderAppearance once instead of forcing the creation of a separate appearance object for every header.
The same thing applies to your RowExporting event. Instead of using:
e.GridRow.Appearance.BackColor = Color.WhiteSmoke
You should create an Appearance object on the e.Layout.Appearances collection and then assign that appearance in InitializeRow. This is all detailed in the WinGrid Performance guide.
Another thing that might help is the RowSizing property. Does your data contain multi-line text? Do you need variable-height rows in the exported document? Or are all the rows the same size?
Using RowSizing.AutoFree means that each row in the grid can be a different height. This uses up memory and slows things down. So I would use a setting that does not include the word Free in it, unless you need to have rows with different heights.
Also, you appear to be looping through the grid columns and calling PerformAutoResize on each one. The UltraGridDocumentExporter already does this based on the setting of the AutoSize property. So I beleive this is redundant and probably takes up quite a lot of time.
Hello Mike
I'm going to take you up on your offer. Attached you'll find the code.
Since I don't really know anything about your application, I can't think of anything else you can do to make it more efficient - other than what's in the WinGrid Performance Guide.
If you want to post a sample I'd be happy to take a look at it and see if there's any way to improve the performance. You could also try running a performance profiler on it. That may give you some more hints about ways to make the performance better.
Regarding capping the CPU time, I don't really see any way to do that, other than launching the export process on another thread. But this is extremely tricky and dangerous, especially when dealing with DataBindng. Personally, I would advise against it unless you absolutely have no other choice.
If you are going to try it, I recommend that you read this thread:
Work with a dataset bound to a grid on a separate thread - Infragistics Community
Thank you for your suggestions.
As it turns out, I was performing duplicate processing for both the grid and the document exporter. Since all I'm using the grid for is the imput for the document exporter, there is no need for me to handle the grids Initializelayout and initializerows events because I can do that in the document exporter events. So I picked up a significant amount of time there. I read the WinGrid Performance Document and set the MaxBandDepth to 1 and the SyncWithCurrencyManage to false. Finally, I changed my DataSource parameter to the SetDataBinding method. All together, the improvement resulted in cutting my cpu time to 5 seconds for the 600 row report. The cpu utilization mix now is approximate 10% in the grid generation and 90% in the document exporting. The larger reports processing has improved as well.
In talking with my director, we've decided that this is probably the best that we can do for now (unless you think of something else). We planning on putting in a cpu time govenor to limit the processing time for the entire report if possible. How would you suggest implementing this or something like it?