Skip to main content

[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic

[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
I've ran into another test : performing the loop in the object method, and the results are terrible...

For 30.000.000 iterations of the same loop :
perform varying compteur
from 1 by 1 until compteur > nbMaxCalc

move compteur to valTest
multiply 100 by valTest

end-perform.


If ran in a subprogram, that takes 4s, and in an object method that takes about 80s...

I guess there's an execution context that differs, but I can't see why since the loop shall be executed the same way in both cases and exept access time to the subprogram or to the class, there shouldn't be any difference.

Where does this huge difference come from???

Any idea?

[Edit] : emptying the perform shows a 18s run time for object call whereas it's instantaneous for subprogram call. Optimizations are default ones in each case (same optimizations), and it's scalable to number of iterations.

Is the compiler non efficient when using objects? If so, is this a bug?


[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
With which product and version number are you testing?
What is the OS and version number that you are running under?

If you think that the results are not as they should be then your best course of action would be to open up a support incident with Supportline and attach the demo program you are using along with instructions on how you created the executable etc.

We can then test it on our side and offer possible workarounds or submit as a possible bug or enhancement request to development.

Thanks.

[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
TahitiClic,

Calls to a subprogram are highly optimised by the compiler and generator and will in most cases simply involve pushing parameters onto the call stack, or registers depending on architecture, and calling the address of the subprogram, apart from the initial call when the subprogram has to be found.

Invokes in native code always involve calling into the OO RTS which resolves the method to be called and then handles the parameters. Because of this indirection it will always be significantly slower. In managed code however the invokes are done directly, there is no intermediate step, so should be much more efficient.

Gael

[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
Hi,

it's Server Express 5

I don't use "managed code", I create and compile it by myself.

We have submitted an incident ticket, at least to have the proper way to do with OO parts.

Regards,
TahitiClic


[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
TahitiClic originally wrote:
Hi,

it's Server Express 5

I don't use "managed code", I create and compile it by myself.


Actually when we refer to managed code we are referring to code that is compiled to run in a managed environment such as the .NET Common Language Runtime (CLR) or Java JVM (Java Virtual Machine).

These are supported by Visual COBOL and Net Express for .NET.


[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
Ok, so I don't use managed code.

[Migrated content. Thread originally posted on 02 September 2011]

Hi,

for computing, I've noticed that calling a subprogram was a lot faster than invoking an object method.

Each time, the exec part is :
move 10 to valRetour.
multiply 100 by valRetour.

For 30 millions of iteration (just the invoke, not the creation of the object which is already existant), I obtain :
7 seconds using a subprogram, and about 170 seconds with the object using.

Is this difference due to compiling options? I think mechanism to locate a method or a subprogram block is the same, isn't it? I don't see why there's a so huge difference.

Regards,
TahitiClic
Hi,

we've found the origin of the problem : we didn't generate well the class executable file, instead of using the .gnt file, the program called the last .int generated file.

Using correct compilation command gives even better results in OO mode (due to compilation optimization).

Thanks for your time,
TahitiClic