I'm looking for a comment re the merits in terms of speed of the use of XLATE vs doing your own file opens / reads / element extract.

Which is faster?

TIA

I have tested the XLATE vs the READO on READNEXT loops with hundreds and also with thousands of iterations. The READO statement is way much faster in my opinion. Be clear that I am talking about READO and not READ.

I am referring to inquiries and reporting and not file updating.

XLATE is more compact and you can pass multiple keys for multiple reads if you wish. Also XLATE does resolve symbolics and dictionary names into field values.

XLATEs are supposed to some form of caching to reduce disk access on redundant reads. I've never tested this however.

It was told to me some time ago that XLATE was faster than doing an Open, read, get var.

But I have found that it really depends on (a) your program and what you want to do and (b) your network (client/server)setup/configuration and PC in combination.

For a quick benchmark try

open file

 read item

    x=item

    y=item

    z=item

vs.

x=xlate(file,id,1,"X")

y=xlate(file,id,99,"X")

z=xlate(file,id,200,"X")

vs.

item=xlate(file,id,"","X")

x=item

y=item

z=item

I would try it after clearing cache or doing several other things, maybe a reboot before each to get a really good stat.

must my 2 cents but we use xlate all the time if we are not really processing the table. It proves to be very fast.

What worries me about READO, is the online help which states:

'In a multi-user environment, ReadO does not necessarily read the most current version of a row.'

Do we know if this is accurate, and what if the UD is in place.

Colin

Xlate values (and READO values) are not guaranteed to be current as they will be fulfilled from local cache. They should not be used for mission critical data. Better for codes and lookups. Xlate will be slower than READO as it does more work.

The Sprezzatura Group

World leaders in all things RevSoft

This seems a potentially huge issue for some.

I would imagine there is a lot of code that uses

xlate to fill a variable then uses that variable

in a calculation to update a field.

Anyone: In a Thin Client/Terminal Services environment how would the caching be handled by the OS and by OI/LH,UD ? One and the same or by user??

So, the implication is that READO and xlate() should only be used on data warehouses with static data, correct?

Never for an app that might actually need the current value of a record/field?

READO has always had the caveat that it doesn't lock the record it reads (so the record might be in the process of being updated), but is an entirely different issue from using a local cache which can be quite out of date. Nor do I remember xlate() as being advertised as having this limitation as well (although it makes sense that uses a reado, since it generally isn't used when wanting to update the same record).

I assume you simply rolled your own xlate() and use that instead in pretty much all cases, right?

In a Thin Client/Terminal Services environment how would the caching be handled by the OS and by OI/LH,UD ? One and the same or by user??

By user.

Intriguing to think of using a RAM Drive on the terminal server to keep a copy of the OpenInsight directory, serve the application from there, have the data on a regular volume.

A couple of our clients now use RAMSANs… la plus ca change la plus c'est le meme chose.

The Sprezzatura Group

World leaders in all things RevSoft

c'est le guerre

Karen, when you say that READO doesn't lock the record are you implying that READ does?

I don't believe either one does a lock. However, I believe both do a GROUP LOCK as they do a read.

Dave

Hi Dave,

This thread made me think… When do "Group Locks" get set? Do they get set on a read/reado or is it just on a write? Do they still occur if we are using a Network Driver? Presumably, this all happens in the background at the server, right? What happens if there is a group lock on group 100 and another user tries to write?

I'm sure all these questions have been asked eons ago but if I ever knew the answers it has been pushed out of my conciousness by more important information.

Thanks,

John

Here is my take on how it works:

ALL read and write operations have to do a GROUP lock. This is done for us by the filing system and is why you get GFE when you don't have proper locking.

You actually don't get GFEs if you don't bother to lock a record ID. The SAVELIST operation (in Arev) doesn't do locks in the LISTS file. I believe you get GFEs because the group lock isn't honored if locking isn't in operation.

When you READ for a record the filing system hashes the ID and reads the .LK frame (of the group) and looks for the ID of the record you want to read, then if not found it jumps to the .OV frames of that group and looks for the ID until it runs out of frames (that belong to that group). Thus, you cannot have the group changing its contents (in any of its frames) during that read operation. A group lock prevents this.

When you WRITE a record the filing system must hash the key to get the group number, lock the group, scan for that ID, if found, then remove data (the record) from each frame containing it, then it writes the record at the end of the group, then unlocks the group.

group lock, if I remember correctly - makes sense it isn't set if it is read from a cache. And I seem to recall different flags/locks being set in old AREV/Novell days (so a reado could execute when file was being resized, while a read could not, at least in tests we did years ago).

I cracked open some old docs - the definition of READO hasn't changed. But versions of the filing system no doubt have. So, old notions of how reado worked are probably somewhat out of date (local cache is no doubt much more common than in 1.0 days).

Interestingly enough, xlate() never has such a caveat attached (at least in the old docs) and neither does btree.extract(). But the provided btree.extract() source in oi (which is probably not current, any longer) does use READO. Just as I would not have suspected an xlate() to use a local cache, I definitely would prefer any index function to use only a current copy of the data on disk.

View this thread on the Works forum...