COBOL "non-myth" confirmed - Index and subscripts (MF on Windows)
in [Cobol]
|
Prev: Help with Tcal
Next: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
From: Pete Dashwood on 16 Sep 2007 21:52 "Robert" <no(a)e.mail> wrote in message news:hvrqe394mgcejqa6bgfvu4ge141tmqtima(a)4ax.com... > On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > > >>(BTW, the reason I use indexes is not for any of the reasons you >>described; >>I simply like INDEXED BY and SEARCH. Having gone to the trouble of >>defining >>an index for a table it seems impolite to then use a subscript... :-)) >>Couldn't care less whether they're faster or slower; on modern hardware it >>makes very little difference, and even if it did, I'd still do it. Because >>I >>can.:-)) > > I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice > as long as they > should for serial, 10% longer for binary. > I NEVER use ODO for ANYTHING. The only time I would code ODO is when I am accessing something that requires it. I've seen the arguments for ODO on searches. As the tables I search are rarely more than 1K in size (I think the largest I can remember doing in COBOL recent was 8K),and I do use SEARCH ALL on non-volatile data, I really don't care if it takes a few microseconds (or even milliseconds) longer. The table is in memory. To me ODO is just ugly pointless code that buys you nothing in terms of saved space, so it doesn't deliver what it promises. The last time I used COBOL for an application that was time critical where a few Milliseconds MIGHT matter (it was a process control app), was nearly 30 years ago and GO TO was employed to get out of routines fast. I wouldn't code normal COBOL apps like that and I don't use ODO in them either. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 16 Sep 2007 22:03 On Mon, 17 Sep 2007 01:23:37 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: > >"Robert" <no(a)e.mail> wrote in message >news:k27re3tjim0q8bsqadfn1ehagf4ko407pj(a)4ax.com... >> On Sun, 16 Sep 2007 06:01:20 GMT, "William M. Klein" >> <wmklein(a)nospam.netcom.com> wrote: >> >>> >>>"Robert" <no(a)e.mail> wrote in message >>>news:rqnoe3hgjei5ir0b6ht4kefrmli2mr2cuq(a)4ax.com... >>>> On Sat, 15 Sep 2007 11:43:24 -0700, Richard <riplin(a)Azonic.co.nz> wrote: >>><snip> >>>> >>>> The Micro Focus page is generalized advice. Write and tell them >>>> generalization >>>> is BAD. >>>> They shouldn't give advice until they test on every machine. >>> >>>Robert, >>> You didn't originally CLAIM this(use index not subscript) was in any Micro >>>Focus documentation. Do you now claim it is in the Micro Focus documentation >>>and if so where? >> >> Micro Focus does not say indexes are faster, in the efficiency tips nor >> elsewhere. Many >> Cobol programmers still believe it, because it was true in the Old Days. >> >>>(Some - but not all - of your original comments WERE about MF documentation - >>>and I would certainly say that some customer who has the relevant >>>documentation >>>and compiler should send in a comment complaining about it. It is worth >>>noting >>>that NONE of the "efficiency" recommendations from your original note were in >>>the Net Express documentation. It - as far as I can tell - never comments on >>>this topic.) >> >> Most of the recommendations are valid, at least on most platforms. I tested >> the ones that >> didn't sound right to me. >> >>>P.S. IBM has some interesting documentation for their z/OS COBOL compiler. >>>For >>>example, >>> >>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/8.1.3.1 >>> >>>talks about some of the table reference optimizaiton that the compiler does do >>>(and therefore what types of code/structures they recommend using for optimal >>>performancer). >>> >>> while >>> >>>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/8.1.3 >>> >>>does recommend the use of indexing over subscripts >>> >>>However, they also "back this up" with the performance statistics that support >>>this, i.e. >>> >>> "using binary data items (COMP) to address a table is 30% slower than using >>>indexes" >> >> Relative speeds are changing. Subscripting was about 500% slower in the Old >> Days. I don't >> doubt it WAS 30% slower when the above was written. My point is that >> subscripts are not >> slower on modern machines. > >You are trying to claim that the zSeries is NOT a "modern machine". > >Your statement, > >"Many Cobol programmers still believe it, because it was true in the Old Days." > >It is still true on the environment where the recommendation is still >documented, i.e. IBM mainframe compilers. (If you haven't researched it, >although the pointed to "Performance Guide" is for Enterprise COBOL V3.1 and the >compiler is now on V3.4, IBM is on record as indicating that there have been few >"performance" enhancements between these releases. > >As you have acknowledged elsewhere, your guess is that somewhere ABOUT 70% of >all COBOL code that is running today is on IBM mainframes (and I would guess >that it is certainly OVER 50^) then it is true that for majority of COBOL code, >the use of indices is to be preferred (for performance purposes) than >subscripts. >And of course, even your own test showed that indices are MINIMALLY faster than >subscripts, so the real question should be WHY would you ever use subscripts >where you could use indices? Your own citation says "subscripting might be easier to understand and maintain."
From: Robert on 16 Sep 2007 22:11 On Mon, 17 Sep 2007 01:43:39 GMT, "William M. Klein" <wmklein(a)nospam.netcom.com> wrote: >An ODO is ONLY faster if the number of "filled in" table entries varies. It usually does. It's usually loaded from a database table or file. > If the >number of entries is stable AND all entries are filled in (which is the most >common situation in the SEARCH ALL programs that I have seen). For serial >SEARCHes where the "empty" entries are at the end, I can't see how or why an ODO >would ever be faster. You seem to contradict yourself. When "all entries are filled in", there are no empty entries at the end. The table is dimensioned with OCCURS to exactly the right size. >P.S. If you search the records of this group, there ARE compilers that have >used non-Binary searches for SEARCH ALL. However, I do agree that no one has >been able to point out any that are still sold/distributed that do so today. There are Computer Science students who would claim that hashing is faster. They are simply wrong.
From: William M. Klein on 16 Sep 2007 22:14 "Robert" <no(a)e.mail> wrote in message news:j6ore39s4saaeccj4mkfsghkb0s0blk19j(a)4ax.com... > On Mon, 17 Sep 2007 01:43:39 GMT, "William M. Klein" > <wmklein(a)nospam.netcom.com> wrote: > >>An ODO is ONLY faster if the number of "filled in" table entries varies. > > It usually does. It's usually loaded from a database table or file. > Agani, your expereince is not the same as mine. In most (certainly NOT all) cases, SEARCH ALL is done on tables of things like "tax codes" "state abreviations", etc. Although ti would certainly be "nice" if such code was dynamically read in, most that I have seen are "hard-coded" and the length of the table is changed when new entries are added (or entries removed). Again, commonly (not always) when a smething needs to be "searched" in a file, a keyed (VSAM on IBM mainframes) are used and access is "direct" via the "searched upon" information. -- Bill Klein wmklein <at> ix.netcom.com
From: Robert on 16 Sep 2007 22:21
On Mon, 17 Sep 2007 13:52:58 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:hvrqe394mgcejqa6bgfvu4ge141tmqtima(a)4ax.com... >> On Mon, 17 Sep 2007 01:17:37 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> >> wrote: >> >> >>>(BTW, the reason I use indexes is not for any of the reasons you >>>described; >>>I simply like INDEXED BY and SEARCH. Having gone to the trouble of >>>defining >>>an index for a table it seems impolite to then use a subscript... :-)) >>>Couldn't care less whether they're faster or slower; on modern hardware it >>>makes very little difference, and even if it did, I'd still do it. Because >>>I >>>can.:-)) >> >> I hope you use ODO on 'high speed' SEARCHes. If not, they're taking twice >> as long as they >> should for serial, 10% longer for binary. >> >I NEVER use ODO for ANYTHING. > >The only time I would code ODO is when I am accessing something that >requires it. The only good ODO is a dead ODO. >I've seen the arguments for ODO on searches. > >As the tables I search are rarely more than 1K in size (I think the largest >I can remember doing in COBOL recent was 8K),and I do use SEARCH ALL on >non-volatile data, I really don't care if it takes a few microseconds (or >even milliseconds) longer. The table is in memory. If it's in MEMORY, speed doesn't matter. I thought you were SEARCHing tables on disk. (How do you do that in Cobol?) >To me ODO is just ugly pointless code that buys you nothing in terms of >saved space, so it doesn't deliver what it promises. > >The last time I used COBOL for an application that was time critical where a >few Milliseconds MIGHT matter (it was a process control app), was nearly 30 >years ago and GO TO was employed to get out of routines fast. I wouldn't >code normal COBOL apps like that and I don't use ODO in them either. It is little known that ODO was invented in Russia. It's a Communist conspiracy to screw up Western software. |