Allen E. Elwood | 27 Oct 2002 22:08
Picon

RE: [U2] [UD] Speedtesting REMOVE was(Exit BASIC program with SELECT list?)

The results of the speedtesting on REMOVE vs. scooping off the top attr are
in.

The winner is...

REMOVE!

SPEEDTEST.REMOVE
How long in seconds? ?10
82202 total loops
8220.2 per second

:SPEEDTEST.SCOOPOFF
How long in seconds? ?10
24338 total loops
2433.8 per second

Using the remove method, the program was able to read a record and process
the attributes 8,220 times per second, while the scoopoff came in a
miserable 2,434 per second, making REMOVE close to FOUR times faster than
scooping off.  Thanks go to Allen Egerton, who obviously shares the same
first name as me, as well as the last initial.

Here's the code from the two speed test programs, in case anyone would care
to test their speed on this construct, or any for that matter.  I picked
this up from a BASIC games book about 20 years ago.  The most simplest form
of the speedtest program is at the end.  When I execute that, I get
1,475,104 loops per second out of my 2.6 GHz P4.  Woof!  My first machine, a
Data General Nova 3 barely got 200 loops per second.

(Continue reading)

Allen E. Elwood | 28 Oct 2002 00:18
Picon

RE: [U2] [UD] Speedtesting REMOVE

Hi Cliff,

The issue that evolved from the original question was which method of
accessing all attributes was the fastest.

If I just setup a loop like the one below, I get only 1833 loops per second.
Until yesterday, I was unaware of the REMOVE statement and it's ability to
quickly access attr's, and had always used the DEL method when outputting
internal print buffers to do the "Page x of xx pages" title deal which came
in faster than simply accessing the next value.

So I setup the tests to see what was the quickest way to access all the
attributes in a record, and REMOVE won.

In that one method really does delete the attr to bring the next to the top,
yes that would technically be apples and oranges, but in that which method
was the most efficient in accessing the next attr, it would be Apples and
Apples.  Or would that be Oranges and Oranges?  Hmm....suddenly I feel like
having fruit....only question now, is should I have an apple or an orange?
;-)

* Release
* CUSTOM
* SPEEDTEST - does what it sounds like
  Version="~Ver=~7.0.3~7775383~"
OPEN '', 'CM' TO CM ELSE OPEN.ERROR<-1> = 'CM'
PRINT 'How long in seconds? ':;INPUT HL
START = TIME()
ENDING = START + HL
COUNTER = 0
(Continue reading)

Allen E. Elwood | 28 Oct 2002 20:38
Picon

RE: [U2] [UV] Term settings for capture and no extra headings

Not sure about UV but in UD there is a NOPAGE option.
                Help Information For: "UNIQUERY NO.PAGE"              Page:
2/3

terminal screen without pausing for page breaks.

:LIST CLIENTS NAME NOPAGE
LIST CLIENTS NAME 10:59:44 Apr 21 1997 1
CLIENTS... Name..........................

9999       Paul Castiglione
10052      Paul O'Hare
llll       kkskskls
10053      Gino Lee
10054      Gregory Alps
10055      Cathy Gross
10056      Samuel Morrison
10057      Subrina Iguano
10058      Antonette Larnelle
.
.
.
9993       Kathleen Donohue

Page 'U'p, 'D'own, 'T'op, 'B'ottom  or 'Q'uit?

-----Original Message-----
From: owner-u2-users <at> listserver.u2ug.org
[mailto:owner-u2-users <at> listserver.u2ug.org]On Behalf Of Buss, Troy
(Logitek Systems)
(Continue reading)

Allen E. Elwood | 29 Oct 2002 17:39
Picon

RE: [U2] [UV] Term settings for capture and no extra headings

There isn't a HDR-SUPP?  If you use this with NOPAGE it should get you what
you want.
hth, aee

Help Information For: "UNIQUERY HDR.SUPP"              Page: 1/2

Syntax

...HDR.SUPP

Synonyms

ECLTYPE U

HDR.SUP, HDR-SUP,  HDR-SUPP

ECLTYPE P

HDR-SUPP, SUPP

Description

The UniQuery HDR.SUPP keyword suppresses the default heading in a UniQuery
report. UniQuery continues to display the column headings.

Page 'U'p, 'D'own, 'T'op, 'B'ottom  or 'Q'uit?

-----Original Message-----
From: owner-u2-users <at> listserver.u2ug.org
[mailto:owner-u2-users <at> listserver.u2ug.org]On Behalf Of Bill H.
(Continue reading)


Gmane