Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!batcomputer!itsgw!nysernic!rutgers!iuvax!silver!creps From: creps@silver.bacs.indiana.edu Newsgroups: comp.sys.ibm.pc Subject: Improve response time with paths Message-ID: <15000048@silver> Date: Tue, 10-Nov-87 23:52:00 EST Article-I.D.: silver.15000048 Posted: Tue Nov 10 23:52:00 1987 Date-Received: Fri, 13-Nov-87 06:25:16 EST Organization: Indiana University BACS, Bloomington Lines: 106 Nf-ID: #N:silver:15000048:000:5372 Nf-From: silver.bacs.indiana.edu!creps Nov 10 23:52:00 1987 Here's a little something I worked up explaining how I decrease response time on my machine. Feel free to send me any comments or questions. - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu A METHOD FOR SPEEDING UP PATH SEARCHING- Steve Creps If you have a hard disk on your MS-DOS system you will want to use the PATH command to tell the operating system where to look for commands when they are not found in the current directory. Not only does this save a lot of typing, since, for example, instead of typing c:\util\arc\pkxarc you can type just pkxarc, but many programs will search this path for support files, which would otherwise have to be in the current directory at runtime. It's obvious that choosing not to define a path is a poor choice. However, there is some cost for doing so. That cost is the time it takes to search the path. If you have a very long search path (that is, one that contains many directories), it can take a noticeable amount of time before it finds the program to be run. Granted that this time probably won't be as much as the time it would take to type the entire pathname of the program, but it still could be improved. One improvement is to create many batch (.bat) files, one for each program that is run often, and put these files into a directory near the beginning of the search path. With these files in place, these frequently- used programs can be found much more quickly. One problem with this is that generally each of these batch files will be under fifty bytes in length, but the smallest increment of file size under MS-DOS is 2048 bytes, on a hard disk. This means about 2000 bytes are being wasted per file, and with very many of these batch files the space waste can become significant. For example, having fifty of these files will waste over 100K, and it still can take a noticeable amount of time to search through that many files in just that one directory. The technical term for this waste of disk space, by the way, is internal fragmentation. Internal fragmentation can be defined as the loss of space due to it being unused, but trapped within a block of space that is being used, and which cannot be broken into smaller parts to free that unused space. My solution is to put these batch files onto a RAM drive (A RAM drive is a logical device which simulates a disk drive using the computer's memory.) An example of a RAM drive is VDISK.SYS, included with MS-DOS. In VDISK the sector size (smallest increment of file size) can be as small as 128 bytes, rather than the 2048 on the hard disk. This means not nearly as much of the RAM drive will be wasted as would be disk space on the hard drive for these files. Even better, the time to scan a RAM drive will be insignificant when compared to that on a hard drive, since RAM is so much faster than even a hard disk. The trade-offs for using the RAM drive are that less memory will be available for running programs, and the files on the RAM drive will be lost every time the machine is turned off. You must copy the batch files to the RAM drive every time you start the computer. Well, it turns out that it doesn't really use that much of the computer's memory, and it's not much trouble to copy them at boot time. Here is how I have my system set up: CONFIG.SYS: device=vdisk.sys 90 (tells it to use 90K in the RAM drive) SAMPLE BATCH FILE (more.bat): c:\util\unix\picnix\more %1 %2 %3 %4 %5 %6 %7 %8 %9 AUTOEXEC.BAT: path=d:;c:\dos;c:\util;... (defines search path, starting in RAM drive d:) cd d: pkxarc c:\etc\batches (this copies all the batch files to drive d:) (see below about the pkxarc command) other start-up commands... The pkxarc command is a program which extracts files from a file archive. This archive can be created with a program called arc or pkarc, and will contain all the files in compressed format, which means they will take up less space. Also, internal fragmentation of the files is virtually eliminated. I keep this archive on my hard disk, and extract the batch files onto the RAM drive at boot time, and it works quite well. In my example experiment to determine the time saved by the RAM drive path search method, I used a timer utility on the "more" command, which types a file. I gave it NUL for input, since we just want to compare the difference it takes to start the program running. The actual more program was still on hard disk, but the batch file in RAM drive let it not have to search the path for very long. The path was still searched for both cases, but the RAM drive speeded the path search significantly. The third case was with the more program in the current directory, so that no path search had to be done. SOME FIGURES FOR MY SYSTEM: Number of batch files: 26 Total size of batch files: 1853 bytes Space used by them on hard disk: 53248 bytes Space used by them on RAM drive: 3968 bytes Size of archive file containing them: 2281 bytes Space it takes on hard disk (frag'ed): 4096 bytes Time taken to extract files from archive onto RAM drive (at boot): 4.6 seconds Time to run "more" command with d:\more.bat: 2.0 seconds Time to run "more" command with path search: 2.6 seconds Time to run "more" when in current directory: 1.2 seconds Clock speed: 8.00 MHz