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: Richard on 19 Sep 2007 16:28 On Sep 19, 11:43 am, Robert <n...(a)e.mail> wrote: > On Mon, 17 Sep 2007 19:37:40 -0400, "Charles Hottel" <chot...(a)earthlink.net> wrote: > > >"Howard Brazee" <how...(a)brazee.net> wrote in message > >news:pabte318v4n344saoq74ifeh7u3t1f8v9n(a)4ax.com... > >> On Sat, 15 Sep 2007 01:50:53 -0500, Robert <n...(a)e.mail> wrote: > > >>>Most people who use indexes believe it. Why else would they use indexes? > > >> Habit. > > >When was the last time anyone posting here ever had a performance problem > >whose solution was related to subscripting or indexing? > > Tell that to the people who use indexes because they THINK speed is a problem and indexes > are a solution. Robert, you haven't demonstrated, or even attempted to, that _anyone_ FALSELY believes this. It is merely an assertion from you that there are such 'legacy coders' and that on their systems indexes are not faster. Just because you have an optimizer that on your system can make subscripts almost as fast as indexes, or faster when doing nothing, proves absolutely nothing about _their_ systems. How much code did you have to rewrite to find something that actually did get optimized away ? First you need to find someone who does actually think indexes are faster, and then you need to show that they are wrong on _their_ system. > Speed is the only reason for using indexes. You have already admitted ignorance about indexes on at least one count. I have shown on my system that indexes _are_ (marginally) faster, and certainly no slower, even against COMP-5 and much faster against COMP. When will you look at actual evidence instead of just your prejudices ? > You showed the premise is false; I showed the solution isn't any faster. If there is no speed difference then the choice makes no difference. It isn't 'indexes' you are attacking it is some 'legacy coders', it is 'choice'. What is it with you. Did you screw up some coding that used indexes and get fired for incompetence and are trying to put the blame on indexes, or legacy coders ? It was all their fault because they didn't know that Robert was superior ? > They probably > aren't convinced by either argument. They'll continue using indexes because .. indexes > were faster in the Old Days and that's what they've always done. Welcome to Cobol-land, > where thirty years ago seems like yesterday. No, Robert, they will continue using indexes because there is _NO_ reason to change.
From: donald tees on 19 Sep 2007 19:32 Howard Brazee wrote: > On Wed, 19 Sep 2007 10:59:14 -0400, donald tees > <donaldtees(a)execulink.com> wrote: > >> I've always believed that 99% of efficiency is in the algorithmic >> design. Once you've decided on the data structure, and the general >> approach to the problem, tiny code level decisions are not going to >> affect the speed much. They will have an effect, sure, but they won't >> fix an inefficient methodology, nor will they completely screw up an >> efficient approach. > > I'm not sure what this means. Does it include moving stuff outside > of a loop that don't need to be in the loop? Does it include > understanding the database processes and structure? Does it include > understanding how to optimize swap space in the OS? Does it measure > the costs and benefits of a CoBOL sort vs. an external sort? > No, the exact opposite. I am saying that by the time you decide what the main loop is, you are probably far enough into it that the major efficiencies are relatively fixed. Maybe by the time you break it down into program modules that is true. Decisions like comparing various sorts are not as important as decisions like "do I sort it, or do I keep it in an ordered data base from the start and do lookups?" > I have a program that looks to see what campus is running that > program. If it is one of the big campuses, it does an area sweep, if > it's one of the small campuses, it walks the set. This was > determined by testing the speeds of the two choices. Closer to what I mean. Two completely different methodologies, depending on requirements. I do not think that something like testing indexing vs subscripting is going to make nearly as big a difference, and is usually a moot point. There are exceptions to every rule, of course, and such a tiny issue may turn out to be important in some very specialized instance, but in the normal turn of things, micro-level coding is a waste of effort. Donald
From: Anonymous on 19 Sep 2007 20:27 In article <X9-dnYZshvgMLGzbnZ2dnUVZ_remnZ2d(a)golden.net>, donald tees <donaldtees(a)execulink.com> wrote: >Howard Brazee wrote: [snip] >> I have a program that looks to see what campus is running that >> program. If it is one of the big campuses, it does an area sweep, if >> it's one of the small campuses, it walks the set. This was >> determined by testing the speeds of the two choices. > >Closer to what I mean. Two completely different methodologies, >depending on requirements. This is one of the reasons I've coded READ INFILE AT END SET NO-MORE-INPUT TO TRUE NOT AT END ADD 1 TO LOOKUP-TBL-ENTRY-NO IF LOOKUP-TBL-ENTRY-NO > MAX-TBL-ENTRIES-ALLOWED MOVE 'LOOKUP TABLE EXCEEDS MAX ENTRIES - CALL PROGAMMING' TO WS-ABEND-REASON GO TO ABEND-RTN ELSE MOVE INREC TO LOOKUP-TBL-ENTRY (LOOKUP-TBL-ENTRY-NO) END-IF END-READ .... or reasonable facsimiles thereof. When data volume goes a certain amount beyond program design then it's time to have a coder look at it... if only to say 'Oh, we're not limited to 32K tables any more, let's bump this baby up a few!'. DD
From: William M. Klein on 20 Sep 2007 01:11 Robert" <no(a)e.mail> wrote in message news:ptl3f3h73j49rr3q148la84am7t8v59r1o(a)4ax.com... > On Wed, 19 Sep 2007 12:52:00 -0500, "HeyBub" <heybubNOSPAM(a)gmail.com> wrote: ><snip> > The problem is I want to talk about Cobol while others want to defend the > mainframe > culture. Perhaps there should be a new newsgroup: comp.lang.cobol.mainframe. > <snip> So, let me get this straight, you want to talk about "COBOL" but not about COBOL as used on mainframes, but by your best guess is that 70% or so of COBOL is running on IBM mainframes. Therefore, you think that the mainframes should get a new newsgroup. Does this seem logical to you? It sure doesn't to me. Now, I did change your "defend the mainframe culture" to "talk about COBOL as used on mainframes", but I think as I read your posts, you think that the latter IS always the former. If I thought that anywhere CLOSE to 70% of the (COBOL-related) posts in this newsgroup were <IBM> mainframe oriented, I would be THRILLED. -- Bill Klein wmklein <at> ix.netcom.com
From: William M. Klein on 20 Sep 2007 01:15
"Robert" <no(a)e.mail> wrote in message news:bhm3f3lhlko53ia8rbjg536gjqc95s344e(a)4ax.com... > On Wed, 19 Sep 2007 13:28:48 -0700, Richard <riplin(a)Azonic.co.nz> wrote: > <snip> > I posted timing tests showing index and subscript run at the same speed. No > one has posted > evidence that indexes are faster. > Did you read the Performance paper for Enterprise COBOL that I have mentioned in a number of posts? Do you think those timings are not true? Do you still think that 70% (or so) of all COBOL runs on IBM mainframes? Again, what am I missing here? (No problem with you saying that if a COBOL program is targeted for Micro Focus on Unix platforms, you have yet to see any evidence that indices are ever FASTER than subscripts. However, that is all you have demonstrated.) -- Bill Klein wmklein <at> ix.netcom.com |