Date Function Performance



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Date Function Performance

Postby rambachi2000 » Fri Mar 18, 2011 11:29 pm

Hi all,

we have Cobol Programs having internal Date subroutines to calculate date difference and converting julian to Gregorian and vice versa
My question is these subroutine are calling for every input record and doing some date calculations.

can we use intrinsic date functions for date difference and converting julian to Gregorian and vice versa(Date-of-integer, integer-of-date) ?
then performance wise which is better(subroutine or intrinsic date functions)
rambachi2000
 
Posts: 9
Joined: Fri Mar 18, 2011 11:14 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Date Function Performance

 

Re: Date Function Performance

Postby Robert Sample » Fri Mar 18, 2011 11:33 pm

You're not going to know which performs better without actually testing each method. There's too much variation in the way things can be coded to just state blindly that such-and-such method is better.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: Date Function Performance

Postby rambachi2000 » Fri Mar 18, 2011 11:37 pm

My question is the internal date subroutine is calling dynamically, every time for each record, why don't we use date functions(converting julian to geo)? I am thinking performance will increase, please advice
rambachi2000
 
Posts: 9
Joined: Fri Mar 18, 2011 11:14 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Date Function Performance

Postby BillyBoyo » Fri Mar 18, 2011 11:40 pm

As Robert has already said, why don't you try it yourself. We don't have your date routines. You try, maybe let us know.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Date Function Performance

Postby rambachi2000 » Fri Mar 18, 2011 11:58 pm

Do you mean, performance wise we can't say which code is best rgt..please advice(confused becoz
calling dynamically will reduce the performance as per my knowledge)

for 1 million input records

the below code will do 1 million times in the same program
suppose I want to convert Gregorian date to Julian using
FUNCTION DAY-OF-INTEGER (FUNCTION INTEGER-OF-DATE (any-date))


The below routine calling 1 million times in the program

call WS-DATE subroutine
rambachi2000
 
Posts: 9
Joined: Fri Mar 18, 2011 11:14 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Date Function Performance

Postby BillyBoyo » Sat Mar 19, 2011 1:54 am

So why are you asking us?

If you're not going to try it, we're certainly not. One might have better performance over the other, but to know if it worth changing for is a different thing. A dynamcially called sub-program is only loaded once, then it is pretty similar to a static call (branch to an address).
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Date Function Performance

Postby Robert Sample » Sat Mar 19, 2011 4:59 am

My question is the internal date subroutine is calling dynamically, every time for each record, why don't we use date functions(converting julian to geo)? I am thinking performance will increase, please advice
Some of the COBOL facilities become in-line code while others become subroutine calls during the compile process. I don't know which way the date functions are implemented, so I cannot tell you that changing from your called routine to COBOL intrinsic functions will have ANY performance difference. There might be, there might not be. If you don't test, you won't know. And since your date routines are not installed at our sites, we cannot do the testing for you.

Performance can be a very complicated subject, since there are many many many factors that come into play. The reason we are telling you (repeatedly) to test is that we cannot know the factors influencing performance of the two methods at your site, so we categorically cannot tell you arbitrarily which method will perform better. You can restate your question 10 ... or 20 ... or 100 times and it's not going to change our answer. Either test both and find out for yourself, or implement one or the other without testing. But do not expect us to just give you an answer -- especially since there's a chance either answer is wrong.
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: Date Function Performance

Postby BillyBoyo » Sat Mar 19, 2011 5:15 am

Dang, that's the second time today I've lost a post (without copying it first) and I also lost one for another poster. Oh well,
it was along pretty similar lines to Robert's post, so I won't bother writing it again. The only things I'd add is that we had a question on March 15 where it turned out exactly those routines didn't work for one site's compiler. If there are performance issues, it is a management decision (sounds like a lot of code to change) and might not be to do with the dates anyway. Why not hold the julian dates as well as the gregorian dates on file, if you are worried it is such a performance problem?

You're asking an impossible question of us, and we're trying to show you why it is impossible. Do the tests and let us know. We don't know, can't know, the date routines are yours, fast or slow. No point in us sagely "guessing".
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Date Function Performance

Postby rambachi2000 » Sat Mar 19, 2011 6:39 am

Hi BillyBoyo and Robert Sample.., thanks for your valuable inputs
rambachi2000
 
Posts: 9
Joined: Fri Mar 18, 2011 11:14 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Date Function Performance

Postby prino » Sat Mar 19, 2011 1:53 pm

I'll add my €0.02

PL/I has a whole series of builtin functions to manipulate dates. Many, if not most, of them (like Cobol, I guess) use LE routines to do the actual conversions. I have PL/I code that works from 0001-03-01 until 9999-12-31, can handle the 10 missing days in October 1582, uses only integer arithmetic and is a hell of a lot faster than the PL/I builtin functions.

Another thing you might want to do is sorting and caching.
Robert AH Prins
robert.ah.prins @ the.17+Gb.Google thingy
User avatar
prino
 
Posts: 536
Joined: Wed Mar 11, 2009 12:22 am
Location: Oostende, Belgium
Has thanked: 3 times
Been thanked: 21 times

Next

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post