cancel
Showing results for 
Search instead for 
Did you mean: 

Crystal Reports version 13 managed api's run slower than native version 11

Former Member
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

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

former_member183750
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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.

former_member183750
Active Contributor
0 Kudos

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

Answers (0)