on 08-01-2014 6:35 AM
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
No replies yet ? Sorry if my question was not clear. I was looking forward from a reply from SAP.
I can give some more info.
I used the Native COM dll (craxdrt.dll) in R2 11.5 (SP6), and using TlbImp, generated the COM interop dll. In our managed code, we used this instead of Crystal 13 Engine dll's, and also explicitly used Threads and marked the threads with ApartmentState.STA. With this we are able to match the performance of the native code.
But when using Crystal 13, we have a good 40% regression. We have similar structure of the code, spawn different threads to do above given template of code.
Why is Crystal 13 managed api, regressing considerably in performance ? Is there a native COM dll for Crystal 13, so I can try similar technique of generating interop COM Dll and try ?
Is there any difference expected if we spawn threads, or use ThreadPool threads, set the ApartmentState etc.
Are we really running multiple ReportDocument.Export concurrently ? Or is it behind the back it is getting serialized anyway.
Thanks for the reply this time
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
First I'd like you to have a look at the document SAP Crystal Reports Engine in a Multi-Threaded Visual Studio Application. Next make sure you are using SP 10 for CRVS.
Next, you will have to tell me what database you are using, connection type and if MS SQL, what client?
BTW.; these being community forums, you may get an answer, you may not. It may be timely, or not. If you are looking for a faster response, there is the option of creating a phone incident here:
Crystal Single Case Technical Support - SAP Business Objects US Online Store | SAP Online Store
One more KBA to look at:
1403341 - How to export reports in multiple threads using the Crystal Reports .NET RAS SDK
- Ludek
Senior Support Engineer AGS Product Support, Global Support Center Canada
Follow us on Twitter
Message was edited by: Ludek Uher
Thank you for the answer.
I am using Oracle database. I don't quite understand what connection type means, in this context. But the way we set the connection info is by the following fragment of code
ConnectionInfo connectionInfo = new ConnectionInfo {
ServerName = "localhost/xe",
DatabaseName = "localhost/xe",
UserID = "testuser",
Password = "testuser"
IntegratedSecurity = false }
TableLogOnInfo tableLogonInfo = new TableLogOnInfo(connectionInfo);
crystalReport.Database.Tables[0].ApplyLogOnInfo(tableLogOnInfo);
This work correctly and renders info correctly. But in our real test where we measured the bench mark, it would be one ip address (as ServerName) above. It works correctly.
It is simple to repro a standalone test case. Just run in a loop of 2000 times, single report creation using Crystal 13 managed api's and using the COM Interop dll obtained from Crystal 11 (or 11.5). Very similar test of comparing apples to apples, I see a 40-50% slower rate in Crystal 13 managed api usage. Here no threads are involved.
Type of connection means:
ODBC? OLE DB? Native? Do not use MS OLE DB Provider, etc. Make sure all is Oracle.
Can't test CR XI R2 as it is out of support and thus no images of it anymore...
You may want to look at the Oracle DLLs / Client loading when you run your CR XI R2 app vs. CRVS app. Use the Modules utility for that.
You don't say if you have updated to SP 10 either...(?).
- Ludek
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.