Article 172991 of comp.os.vms:
Jim Mehlhop wrote:
> 
> There is no hard limit, however there is an effective limit.  If the
> .dir file grows to a size larger than 127 blocks then directory caching
> will be disabled and access will be EXTREMELY slow.

The 127 block limit is actually in RMS's wild card scanner. Up to this
directory size, RMS reads and interprets the directory contents when
called with wild card operations (e.g., $PARSE / $SEARCH) to avoid the
overhead of a trip to the base file system for each lookup. You'll see
this most dramatically in directory listings. However, this limit has no
effect on vanilla application file opens. These go straight to the base
file system as part of the open call. The base file system has its own
directory cache, controlled by SYSGEN parameter ACP_DIRCACHE. (Ths is a
shared cache for all directory operations.)

The real killer on directory performance is directory shuffles. The file
system keeps directory entries in lexical order to allow search
optimizations. Individual directory blocks are partially filled, but
when a block overflows or goes completely empty, the file system splits
or removes the block accordingly. This involves copying the entire tail
of the directory up or down one block, and this operation is
unfortunately done one block at a time. So with a big directory, the
occasional create or delete sudenly gets  R E A L  S L O W.

With normal random file naming behavior, directory shuffles are
infrequent. However, non-random behavior can cause problems. A classic
case is a DELETE *.*;* on a big directory. The file wildcarding of
course returns the files front to back, and so files are deleted from
the front of the directory - precisely the worst order. So the time to
delete all the files in a big directory goes with the square of the
number of files. If the directory is really huge, it's well worth
building a command procedure to delete the files back to front.

Another common cause of poor directory performance is large collections
mail files. The algorithm used by MAIL to generate the MAIL$nnnnnnnnnnn
file names creates names that are mostly ascending over time. (They wrap
around roughly once a year.) This means that new mail files are always
added at the end of a directory. Typically, mail messages decay with age
- the older they are, the fewer you've kept. Couple this with the
creation of new files at the end of the directory, and mail directories
become increasingly sparse over time because the file system doesn't
collapse directory blocks until they're completely empty. So mail
directories tend to get excessively large, even for the number of files
in them. It's well worth cleaning this up by switching to a new mail
directory every couple of months with SET MAIL_DIRECTORY. This moves the
files to a new directory, repacking it in the process. (Again, done in
forward order, good for the new directory, bad for the old one which
suffers from the aforesaid front to back problem.)