Skip to main content

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

Hi Noj, do you have any details of where the degradation lies? Are you doing a lot of file handling or database access?

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

It appears to be in some modules that perform interest rate calculations and related math. The time difference is not large...a few seconds per policy but it adds up when we're processing thousands of policies. Some of the modules are called over a hundred times. In native code this area of the code may take a second whereas in managed code it's taking maybe 3 seconds.

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

There may be some file access but no database access at this level.

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

In managed COBOL, you may get significantly better performance by using native (CLR or JVM) types to perform calculations, rather than items defined with COBOL PIC clauses. So try doing your calculations in temporary items declared as binary-long or whatever is appropriate, then move the final result to an item with the appropriate PIC clause.

The topic "COBOL Type Compatibility with Other Managed Languages" in the Visual COBOL documentation describes the native types available for managed COBOL programs.

We are converting a large admin system to managed Visual COBOL 2.0 from native Net Express 5.0 and have noticed a significant performance decrease in our batch processes. Running the same process on the same PC with the same data, Visual COBOL appears to be up to 4.5 times slower than the natively compiled code. I read in one post that a configuration setting to license manager solved the problem and in a prior incident report switching from comp-3 to comp-2 was a work-around. Are there any performance tuning tips you can send my way?

Hi Noj, thanks for the information so far - the support team tell me they have an incident open for this which we're looking into now.

If you can provide us a small cutdown we can advise on interim workarounds.

Terms & ConditionsAccessibility statement