From: Richard on
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
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
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
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
"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