I learned terminal I/O problems last millennium.

Unfortunately I wrote neither the code nor did I design the files. I
just want to speed the silly thing up.

It also appears that each record is getting several MVs added, so each
record is effectively getting larger with each WRITE ... yea ... :-/ ...
it must have seemed like a good idea at the time.

(My apologies for whining)

David Laansma
IT Manager
Hubbard Supply Co.
Direct: 810-342-7143
Office: 810-234-8681
Fax: 810-234-6142
"Delivering Products, Services and Innovative Solutions"

-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Monday, April 30, 2012 9:22 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] READU vs READ

(Saw other responses come in as I was writing this - oh well, this might
help someone else...)

> From: Dave Laansma
> If I don't HAVE TO lock a record before modifying it writing it
back, will a
> program run significantly faster if I just WRITE it back without
locking it
> first? I'm updating about 700,000 records and it's just taking TOO
> I DO understand the risks of other users changing the record's
> during so let's not go down that road. I'm interested in the SPEED 
> dialog.

I don't know what you meant by "SPEED dialog" but if WJ is right and
you're displaying an item count as you run through records, then he is
also right that that IO will destroy performance.

Try this as related experiment: Loop to display the numbers 1 through
1 million. Watch it stream on your terminal emulator. Now run it again,
minimize the emulator, then re-normalize it. I believe you will find
that while the output was hidden it streamed through most or all of the
output. Same thing happens if you're doing a copy or delete and tapping
your fingers as you wait for the IDs to  stream by - a watched kettle
takes longer to boil... :)

About READU vs READ... You're doing a READU just because you're doing a
WRITE? Nah, if you don't care about contentions don't bother to ReadU.
You're reading and updating lock tables and semaphors with READU and
that's huge performance hit.

Here's another experiment: When you're copying or restoring items, use
the appropriate option to overlay items, even if you know the target
file is empty. Why? Because Copy needs to do a Read first to see if it
needs to warn you about an existing item. If you tell it to overlay it
will just do the Write (sure, there's a lower level read there anyway
but less code is executed).

Combining these... if you use a Copy (Pick flavor, don't recall options
otherwise) with both overlay and ID suppress, it avoids a ton of
internal DBMS code, so it goes a lot faster than a no-option copy.

I haven't benched those scenarios for years. If anyone does the tests,
please let us know if this is valid or not, and your DBMS/flavors.


U2-Users mailing list
U2-Users mailing list

Reply via email to