Accessing _Lock VST takes a long time

Accessing _Lock VST takes a long time
The time taken to read _Lock does not scale linearly to the number of locks. It scales exponentially.
Reading _ Lock is very slow.
Slow performance using the _Lock VST table.
-L (Lock table size) is large

This is expected behavior.

The _Lock table is not indexed in any way. Reading the lock table VST is slow because the underlying data structures of the lock table are not organized as a simple table. They are significantly more complex and also the structures change while they are being read. That makes the conversion into a flat table slow when the lock table (-L) is large.

This Article does not apply to OpenEdge 11.4 and later.

The behavior of the _Lock VST changed starting with OpenEdge 11.4: Performance of the _Lock VST now directly scales with total size of lock table instead of active locks, and will show much better performance in most cases. Refer to Article  Entries in _Lock no longer appear at top of resultset from OpenEdge 11.4 onward for further details.

Prior to OpenEge 11.4:

• When a record with an unknown value for a lock status field such as _Lock-Usr or _Lock-Recid  is reached, exit the query. Records with unknown values in these fields are unused records; they do not represent current locks.
• Queries on _Lock can be sped up by aborting the loop if a field other than _lock-id becomes unknown.  This will ensure that data is read only for the locks that are actually in use, not for unused records.
• Specifying the check for unknown values in the WHERE clause is less effective due to how the query mechanisms work in this particular instance. The difference will be smaller if large numbers of records are being locked.
• As of this writing there are no plans to index the _Lock table.
• Example:

FOR EACH _Lock NO-LOCK:
    IF _Lock._Lock-Usr = ? THEN LEAVE.
    /* other code here */
​END.

Sample _Lock Table code:

• Scanning only the non-empty _lock records:  Article  4GL/ABL: How to check whether a given record exists, locked by another user or does not exist? 
• Using Temp-Tables to enhance the performance and limit the processing scope of the _Lock table: Article  How to monitor locks using VST?   

In some cases, the _Userlock VST will suffice.  It shows the first 512 locks associated with a particular user and is very fast since it does it in one request and stores the entries in an array. Article  What is the Record locking table _UserLock   

References to Other Documentation

Progress Articles:
 4GL/ABL: How to check whether a given record exists, locked by another user or does not exist?
 Why does the _Lock table have records where _Lock-Usr = ?
 Entries in _Lock no longer appear at top of resultset from OpenEdge 11.4 onward