(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 long. > > I DO understand the risks of other users changing the record's content > 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. T _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
