Hi all,
I have an application that exports a grid to PDF. I handle several events to make changes to the layotu of the grid so that it looks more like a report in the PDF document.
We've been testing the speed of generating the report and have noticed that the difference in exporting 10, 20 or 30 thousand rows does not differ (only by a few seconds - taking over 5 minutes in total). We're filtering the rows down from 30,000 to test - expecting that it would be quicker. There is also no difference between 50 and thousands of rows either...
Does anyone know what factors affect the performance of the PDF export?
Is it the number of rows (regardless of any filters), the number of columns, the number of pages it produces etc.?
We have found that collapsing any groups in the grid does speed the report generation greatly, however.
Any help will be greatly appreciated.
Cheers,
Richard
Hi Richard,
Are you saying that it takes 5 minutes to export 50 rows? I can understand thousands of rows taking that much time, although it still seems pretty high and I've never seen it take that long. It also depends on the speed and RAM on the machine.
But if you have a sample which demonstrates 50 rows taking 5 minutes to export, I'd love to see it, because there's clearly something very wrong there.
Have you tried running it through a performance profiler?
What version are you using?
Sorry mike i didn't respond to your other questions:
No, I haven't tried running it through a performance profiler, and we're using 2010.3 with the latest hotfix (2015).
Whether the rows are hidden or not, the exporter still has to loop through them at least twice - first to fire the InitializeRow event (in which you might be setting the hidden property of the row), and the second time when it actually goes to export that row. So the filter probably won't have much effect on exporting.
If you know that you only have a small set of visible rows and you want to improve the exporting performance, my advice would be to create a second WinGrid in code. You can copy the visible rows in your real grid into an UltraDataSource or a BindingList<T> and bind it to the grid behind the scenes. You would also save the DisplayLayout of the real grid and copy it to the new grid. And then you can export it with just the rows you need.
Thanks for the info., Mike. The InitializeRow event is the only one that we're using that fires for every row (regardless of filtering). But all we do for each row is check if it's a group row. If it is then we tell it to skip all decendants (if collapsed). Otherwise, nothing will be done. Are you saying that simply the fact it fires this event and does this check is what is causing it to run slowly?
It's a dynamic report generator, for which we have no knowledge of what data the user wishes to input. It could be 10 rows, it could be 10,000. Thanks for the suggestion, but I think in the cases with a large number of rows, this will be causing it to go slower. I could do one or the other, depending on how many rows are filtered, however, I guess...
Thanks for your help, Mike. If I get a chance to build a sample app, I will submit it here or to the support team, directly.
Richard said:Are you saying that simply the fact it fires this event and does this check is what is causing it to run slowly?
Well, it doesn't sound like you are doing anything that should cause a slowdown. If you comment out that code, does that improve the performance?
Okay thanks, I'll try that. It may be a little while before I get back here with that, though... we're currently much more concerned about this issue we're experiencing:
http://community.infragistics.com/forums/t/50231.aspx
If you could help us out with that, I'd be ever so thankful! =)
But I'll have a look into this report performance, and see if I can find out where (if any) the time is taken up in exporting the report. Thanks for you help so far, Mike!