Hello,
I am a senior engineer, working in a project of porting client code written in C++ using Crystal 11. It uses the native COM api like shown approximately in the following code fragment:-
IApplicationPtr pApplication;
pApplication.CreateInstance("CrystalRuntime.Application.11");
pReport = pApplication->OpenReport("myreportfile.rpt", vtOpenMethod);
... code to setup Export Options, setLogonInfo on database, set parameters for report etc.
pReport->Export(false);
This code is launched in few threads, and works nicely, and a very stable used code in real world.
We have ported this to Crystal 13 .NET api's and our code approximately looks like
ReportDocument document = new ReportDocument();
document.Load("myreportfile.rpt", OpenReportByTempCopy);
.. set diskfile format options, pdf format options, paramters, logon info etc. very very similar to the native C++ code, almost matching 1 by 1 line
document.Export();
document.Close();
No problem so far, and it works fine. This is also launched in multiple threads same in number like native, and works fine. We get the same pdf file generated.
But here is the problem. In native we are getting easily around 2000 reports in 20 mins. But in managed we are taking 35 mins for the same set of reports. The output looks fine and same etc. But there is a good 40-50% performance regression, and we have tried so many things, but never able to beat this 40-50% perf degradation.
Can you please help ? A few questions. First are we executing document.Export really concurrently ? Is there any waiting or serialization going on insider Crystal api's. Is this Crystal 13 managed api, a thin stub layer just passing on to native COM apartment threaded dll. Can this layer introduce such a delay ?
A few things we have tried and haven't succeeded for summary:-
1. Opened 1 dummy report in the beginning and kept opened throught, to flush any ref counted inits
2. Didn't perform Close immediately, but had another thread chew on it and Close delayed
3. Reduced the thread to 1, (in native as well), again our perf degradation is comparable.
4. Optimized the reports from various suggestion in this forum. Did better, but so did the native, and still we are comparatively poorer.
Thanks for the same, Eager to supply more info if required.
R. Sridharan