creps@silver.bacs.indiana.edu (11/11/87)
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
jai@im4u.UUCP (Jai Srinivasan) (11/11/87)
In article <15000048@silver> creps@silver.bacs.indiana.edu proposes
the use of a ramdisk to store BAT files that start up programs and have
the ramdisk as the first directory of the PATH variable. The advantage
being that in most cases most directories of the PATH do not need to
be searched as the BAT file will be found on the ramdisk and it will
have the entire directory name of the program that needs to be run.
Here is an alternative to using BAT files. Get CED and use its synonym
feature. In addition to being an excellent command line editor, CED
can store abbreviations for commonly used commands. It has the ability
to re-order parameters from the command line (the %1 .. %9 of BAT files)
and it can expand a command into more than 1 DOS command. Best of all,
it is in public domain and virtually bug-free. (An updated commercial
version called PCED is also available from its author.)
Here is a sample of the power of CED. To those accustomed to aliases
on a UNIX system, there is nothing novel in this. Others may find it
useful though.
SYN av c:\etc\archvrs\pkxarc /v
SYN am c:\etc\archvrs\pkarc /Oc /m
SYN ae c:\etc\archvrs\pkxarc
SYN dcp for %i in (c:\bin\misc\list.com c:\bin\misc\ls.exe c:\bin\misc\cd.exe) do copy %i d:
Now av is an abbreviation for "c:\etc\archvrs\pkxarc /v". The rest of
the command line after av is plugged in after "c:\etc\archvrs\pkxarc /v".
Similarly for the am and ae. The last command re-initializes my ramdisk
by copying specific files into it.
A more complicated example:
SYN Starttimer C:\Etc\Norton\Timer /c%1 start /n /l
Now typing "StartTimer 2" causes the command
C:\Etc\Norton\Timer /c2 start /n /l
to be executed. Other synonyms can juggle around parameters even more.
Finally an example that causes one command to execute more than one DOS
command:
REM Replace the file (first argument) by the output of the command
REM (arguments 2 thru the last argument) with input the file of
REM the first argument. Useful for filters that do not accept files
REM but require input from stdin.
REM
REM Eg: rplc thisfile sort OR rplc thisfile tr A-Z a-z
SYN rplc c:\bin\misc\mv -i %1 !CED!_!-.tmp ;%2 %3 %4 %5 %6 %7 %8 %9 < !CED!_!-.tmp > %1 ;del !CED!_!-.tmp
The ';' (the "chain character" of CED) separates 2 commands. So the file
%1 is first renamed to !CED!_!-.tmp, then the filter is executed and its
output sent to %1 and finally the temporary file !CED!_!-.tmp is deleted.
--------
Jai Srinivasan, UUCP: {gatech,harvard,ihnp4,pyramid}!ut-sally!im4u!jai
ARPA: jai@im4u.UTEXAS.EDU, jai@sally.UTEXAS.EDU
-----------------------------dick@plx.UUCP (11/12/87)
Expires: Sender: Followup-To: Disclaimer: I wrote it. Nobody else. Just me. In article <2408@im4u.UUCP> jai@im4u.UUCP (Jai Srinivasan) writes: >Here is an alternative to using BAT files. Get CED and use its synonym >feature. [...] First two qualifiers: 1. I also think CED is the slickest thing since [fill in the blank]. 2. I am not familiar with PCED. However, the biggest drawback I have found with plain, vanilla CED is that, unlike batch files, it cannot be invoked by: o other batch files (limited facilities prior to DOS 3.3) o for..in..do constructs o cannot be forked/exec'ed from within executing tasks Awhile ago a fellow on GEnie said that, since he got CED, the only batch file he has anymore is his AUTOEXEC file. Wellllllllll, as limiting as current DOS batch files are, to replace all batch files with CED synonyms is to either abuse CED or have only very simple batch files to begin with (try an 'if exist..goto..' under CED). So in my opinion CED is an invaluable supplement to regular batch files, but cannot--and should not--replace them. -- Dick Flanagan, W6OLD I'll take a drug test when UUCP: ...!ucbvax!sun!plx!dick Reagan takes an IQ test. GEnie: FLANAGAN
wsd@whuts.UUCP (DINSMORE) (11/12/87)
## In article <2408@im4u.UUCP jai@im4u.UUCP (Jai Srinivasan) writes:
##
## Here is an alternative to using BAT files. Get CED and use its synonym
## feature. In addition to being an excellent command line editor, CED
## can store abbreviations for commonly used commands. It has the ability
## to re-order parameters from the command line (the %1 .. %9 of BAT files)
## and it can expand a command into more than 1 DOS command. Best of all,
## it is in public domain and virtually bug-free. (An updated commercial
## version called PCED is also available from its author.)
##
## Jai Srinivasan, UUCP: {gatech,harvard,ihnp4,pyramid}!ut-sally!im4u!jai
## ARPA: jai@im4u.UTEXAS.EDU, jai@sally.UTEXAS.EDU
##
I have tried to locate this program and can't find it. I do NOT
have access to an FTP server. I tried several BBS's to no avail. If some
kind soul would please mail this to me I would be very grateful. I
would also like to get the address of the author for PCED if it is not
already included with CED. Thanks in advance.
Wayne S. Dinsmore
UUCP: ihnp4!whuts!wsdhoctor@osiris.cso.uiuc.edu (11/12/87)
One other consideration is to keep your directories compacted. Erased files still take up space in the directory and must be looked at when searching for a file. Every disk defragmenter that I know of will remove these erased entries and compact the directory. If a directory is particularly active (many files being created and erased) the benefits of compacting is dramatic. If your path contains a directory with 2/3 erases entries (not unreasonable if you have never de-fraged) then the search of that directory could take 3 TIMES as long! So if you don't want to go through the trouble of RAM disks and archives, you can greatly enhance performance (of PATH searches, global disk searches, etc.) by keeping your disk defragmented. One shareware defrager (SST) even has a command line option so that it will only compact directories. If you havn't defraged in some time, you should try to get SST and use it. It will display how many erased entries have been removed; the the numbers can be shocking. hoctor@osiris
tom@tsdiag.UUCP (11/13/87)
I do the same thing only slightly differently, I have a program called DOSEDIT which allows editing of the previous commands entered, and it also allows ALIASes so to run my editor i just type "emacs" which gets converted to C:\EDITOR\EMACS\EMACS.EXE or what ever, it works great. Yes, I still set my path for aux file lookups along with the SEARCH utility that catches all DOS open calls to check it's own [modifible] search paths [norton utility Speed-Disk works wonders too...] c'ya -- Thomas A. Moulton, W2VY Life is too short to be mad about things. Home: (201) 779-W2VY Packet: w2vy@kd6th Voice: 145.190 (r) Work: (201) 492-4880 x3226 FAX: (201) 493-9167 Concurrent Computer Corp. uucp: ...!ihnp4!hotps!ka2qhd!w2vy
dennis@rlgvax.UUCP (Dennis.Bednar) (11/13/87)
In article <2408@im4u.UUCP>, jai@im4u.UUCP (Jai Srinivasan) writes: > In article <15000048@silver> creps@silver.bacs.indiana.edu proposes > the use of a ramdisk to store BAT files that start up programs and have > the ramdisk as the first directory of the PATH variable. The advantage > being that in most cases most directories of the PATH do not need to > be searched as the BAT file will be found on the ramdisk and it will > have the entire directory name of the program that needs to be run. > This is slightly off the topic, but certain versions of the UNIX shell cache command names in memory of the running shell (translate shell to COMMAND.COM for MSDOS). If the command & directory is not in memory, a full directory search occurs, and if found, is added to the in-RAM cache. To look at the cache, there is the "hash" command that the user can type in. There are also commands to forget the cache, useful say, if you add a private "ls" command, and want your private ls command to be found *first* before the public one already in cache. With the way MicroSoft is migrating MSDOS to look like UNIX, perhaps a future version of COMMAND.COM will have such a feature. Personally, I think that path caching is a better approach than usinge hard-coded aliases used by CED, (suggested by another person on the net). -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300