Answered Doubt about function/procedure efficiency

[Guilherme Araujo]

First of all, I'd like to thanks this community, for I have solved more problems regarding to Progress then I can count with the threads available in this forum. For this you alredy have my thanks.
Also, I'm very new to both Progress programming and to progresstalk, so either if this thread is posted in the wrong place or if my doubts are senseless, just ignore it.


Now... to the doubts I have themselves...
I've been reading too many codes here in the place I work, written as ABL procedures. And sometimes I see blocks wich are written as procedures, with any number of INPUT parameters and a single OUTPUT parameter and as functions, wich are associated with a return value and any number of INPUT parameters.
That got me wondering about if there is any difference regarding to the code efficiency of using one or another. Also, if in the cases above, when there is no more then a single OUTPUT parameter for procedures, if it would be better to use functions instead.


Many many thanks,

Kind regards, Guilherme.

 

[RealHeavyDude]

If I remember correctly then some 10 years ago somebody made some performance tests of procedure versus function calls. As far as I can remember the difference was negligible. I would not chose a function over a procedure or vice versa because of performance considerations. But, frankly, I have no evidence to prove anything.

From the coding perspective I like functions better because they are more like methods that I know from other languages. Plus, if you call an interal function locally the compiler will check the parameter signature whereas with internal procedures there is no check at compile time whatsoever. If you need more than one output parameter you can even go as far as to specify and output parameter in the function sginature. Whether that is good clean code might be subject to discussion. For example in Java I sometimes miss the possibility of that because I need to code a wrapper Java bean to just have more than one output. But then again this is OO and you can do the same thing in the ABL now - have objects in parameter signatures ...

Bottom line: I mostly use functions.

Heavy Regards, RealHeavyDude.

 

[Guilherme Araujo]

Thanks for the quick response RHD.
That was pretty much it. Now, I just don't know whether this is good practice to work with output parameters into functions signatures. Any toughts on that? Also, both procedures and functions work the same with complex data types in their signatures?
And to finish this thread, calling functions/procedures from an external scope, from another file or what so ever is the same? Even there wouldn't be any performance issues?

Kind regards,
Guilherme.

 

[Cringer]

Output parameters in a function are probably a question of taste, although from a purist perspective they break the rules on functions. On the other hand you could argue that as the functionality is there there's no reason not to use them.
In terms of performance differences between them I don't think it makes a jot of difference.
As for Procedure or function? I think it depends on the complexity. I was always taught that functions are for small pieces of logic that will be repeated many times. They shouldn't call out to other procedures really. Procedures are for more complex operations.

 

[Guilherme Araujo]

Hello Cringer,

Thanks for the toughts. If the issue goes down to a purely purist matter, then I see no problem using all of the language's resources and put it into use some OUTPUT parameters into a function's signature, whenever I need more then a single value returned from the function's scope.

Also, for what I've seen then there is no big difference regarding the performance towards the use of either a procedure or function, so I guess your criteria is as good as any. Functions for small pieces of logic code, used often. And procedures for larger blocks of code.

Thanks for all the help.


Kind regard,

Guilherme

 

[tamhas]

Of course, you can move them all to methods and be more up to date ...

 

[GregTomkins]

IMO, there is one solid reason to prefer external .P's (not internal procedures or functions): by using them, you are *forced* to isolate all variables and buffers. With Functions and IP's, there is nothing (compiler-wise) to stop you from doing this kind of thing:

DEF VAR x AS CHAR INIT 'A'.
FIND order WHERE order.num = 1.
RUN do_thing.
DISP order.num. /* displays '2,B' but we expect it to display order '1,A' */

PROCEDURE do_thing:
FIND order WHERE order.num = 2.
x = 'B'.
END.

Yes yes yes, proper discipline, standards etc. would prevent this. But that's hard to maintain across dozens of developers, three offices, thousands of files and 20+ years. And, I don't see a lot of upside to Functions/IP's: just #1) the compile-time checking that RHD mentioned, definitely; #2) more efficient, but 99% of the time, that doesn't matter.

 

[GregTomkins]

IMO, there is one solid reason to prefer external .P's (not internal procedures or functions): by using them, you are *forced* to isolate all variables and buffers. With Functions and IP's, there is nothing (compiler-wise) to stop you from doing this kind of thing:

DEF VAR x AS CHAR INIT 'A'.
FIND order WHERE order.num = 1.
RUN do_thing.
DISP order.num. /* displays '2,B' but we expect it to display order '1,A' */

PROCEDURE do_thing:
FIND order WHERE order.num = 2.
x = 'B'.
END.

Yes yes yes, proper discipline, standards etc. would prevent this. But that's hard to maintain across dozens of developers, three offices, thousands of files and 20+ years. And, I don't see a lot of upside to Functions/IP's: just #1) the compile-time checking that RHD mentioned, definitely; #2) more efficient, but 99% of the time, that doesn't matter.

 

[tamhas]

And, of course, with OO you get the best of both.

 

[RealHeavyDude]

External procedures won't help when used in conjunction with infamous include files that declare shared variables all over the place. I don't think specific language features promote or hinder good practice. It is up to the developer to produce "good" code.

If the usage of external procedure prevent the usage of shared varaibles for you it might be a good thing for you to follow that practice.

Heavy Regards, RealHeavyDude.