Oriented object performance

D

dubej00

New Member
Can you tell me why the following code is very slow (about 37 seconds on my PC) :

Code: 
USING cls.Test.

DEFINE VARIABLE i     AS INTEGER INIT 0.
DEFINE VARIABLE aTest AS CLASS   Test.

ETIME(YES).

REPEAT i=0 TO 1000:

    aTest = NEW Test().
    DELETE OBJECT aTest.
END.

MESSAGE ETIME / 1000.

And the class cls.Test :

Code: 
USING Progress.Lang.*.

ROUTINE-LEVEL ON ERROR UNDO, THROW.

CLASS cls.Test: 

END CLASS.

Thanks!
 
This takes 0.157 seconds on my machine (Vista x64 on i7 920 @ 2.67) running OE10.2B02 x64...

Are you sure you are getting the test class you think you are getting?
 
Stefan said:
This takes 0.157 seconds on my machine (Vista x64 on i7 920 @ 2.67) running OE10.2B02 x64...

Are you sure you are getting the test class you think you are getting?
Click to expand...

Yes, I'm getting the right class.

It takes 0.519 second on our Unix central server and 5.19 seconds if I increase the loop to 10000.

5.19 seconds : is it really an acceptable time?

We are running OE10.2B01, is there improvements with SP02 and SP03?

Thanks!
 
I do not yet use classes, so I have no idea if this is fast or slow.

I adjusted the test to run an empty procedure persistently 10000 times, this takes 1.14 seconds (uncompiled).
With empty procedure compiled: 0.76 seconds

With classes (compiled): 0.88 seconds

So:
  1. define 'slow'
  2. why (on this scale) does the time to create 10000 objects matter?
 
Stefan said:
I do not yet use classes, so I have no idea if this is fast or slow.

I adjusted the test to run an empty procedure persistently 10000 times, this takes 1.14 seconds (uncompiled).
With empty procedure compiled: 0.76 seconds

With classes (compiled): 0.88 seconds

So:
  1. define 'slow'
  2. why (on this scale) does the time to create 10000 objects matter?
Click to expand...

  1. Hard to define, we are just starting the use OO
  2. Our first use of a class is to encapsulate references rows from a table (ex.: a client). In a report, for each line of the report, we need to create few objects to get fews properties...

Thanks again!
 
Personally I think OO with Progress doesn't make sense - procedure oriented approach is more practical with high level languages. New improvements to Progress language make it more and more similar to .NET languages and one day there will be no point in using Progress when you can use C# - pure 4GL is more readable (and faster) than OO code.
 
On my system it takes 0.03 seconds uncompiled and 0.025 seconds compiled.

Do you maybe have a PROPATH with a zillion or so entries in it?

What sort of system are you running your test on?
 
TomBascom said:
On my system it takes 0.03 seconds uncompiled and 0.025 seconds compiled.

Do you maybe have a PROPATH with a zillion or so entries in it?

What sort of system are you running your test on?
Click to expand...

Right on the target! I wasn't aware that the PROPATH's entries can have this impact.

Thanks you very much!
 
Blanket rejection of OO in ABL is silly. Much of the programming world has recognized that OO provides a superior development paradigm. E.g., see http://www.cintegrity.com/content/Object-Orientation-Why-When-and-How .

Which said, one has to recognize that ABl is a 4GL which is pseudo-compiled and that there are some operations which are very fast and low overhead in 3GL OO languages which turn out to be non-trivial in ABL. Periodically, someone will post on some forum about I did X in ABL and in C# or Java or something and look how terrible the ABL is. Most of the time, it is a stupid comparison because it is doing something far more than one ever would in reality and doing so in a tight loop with no other activity. I.e., the right way to benchmark and isolated function, but possibly meaningless in the real world.

Here, for example, we have isolated creating the class, but have no code for populating it or using it. Setting aside for the moment the OPs time which seems to be much higher than any one else's, we have 1000 iterations in, for example, .157s or .000157s per iteration. Now, possibly that is a long time relative to C#, but it is an amount of time which is, at the least, unlikely to ever be noticed by a user. Surely, populating the data and using it will consume vastly more time. So, let's put this in context. If you have a performance problem in context, then use this kind of test to isolate the source of the performance problem, but as an isolated test it is meaningless.

There is the OP's test which is a lot longer ... so one might ask questions about how long it takes for fewer iterations and then wonder if the user's PC was memory starved or doing something else at the time.

Which said, there are not a lot of circumstances in which creating 10000 objects makes a lot of sense. Is there meaningful business logic associated with each object? What are you encapsulating? Is the nature of the problem such that one or a smaller number of objects, each containing more data makes sense? One doesn't really have enough information here.

Note that a 10,000 line report means something like a 200 page report with 50 lines a page. Not many 200 page reports are actually useful.
 
You must log in or register to reply here.
Back
Top