akoivuma@finsun.csc.fi (Antti Koivumaki) (05/20/91)
I have noticed that when I use 4dos.com, erase *.* works much slower than when command.com is used. I tested this by erasing 100 files using each. I did this on an otherwise empty hard disk partition. The result: - using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds - using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. A bug or a feature? Any explanations? ****************************************** Antti Koivumaki akoivuma@finsun.csc.fi Technical Research Center of Finland Telecommunications Laboratory
komarimf@spiff.soe.clarkson.edu (Mark Komarinski) (05/20/91)
akoivuma@finsun.csc.fi (Antti Koivumaki) writes: >I have noticed that when I use 4dos.com, erase *.* works much slower than >when command.com is used. I tested this by erasing 100 files using each. >I did this on an otherwise empty hard disk partition. The result: >- using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds >- using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. >The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. >A bug or a feature? Any explanations? I think it's a combination of both. From your findings, I'd have to assume 4dos expands the *.* before deleting and then performs a separate delete for each file (that's probably why it can tell you the names of each file deleted). Using the /q option just prevents 4dos from telling you what it deleted. -- - Mark Komarinski - komarimf@spiff.soe.clarkson.edu Credo quia absurdum est - "I believe because it is absurd" -- - Mark Komarinski - komarimf@spiff.soe.clarkson.edu Credo quia absurdum est - "I believe because it is absurd"
ins845b@monu4.cc.monash.edu.au (mr k.l. lentin) (05/20/91)
In article <1991May20.064529.1764@nic.funet.fi> akoivuma@finsun.csc.fi (Antti Koivumaki) writes: >I have noticed that when I use 4dos.com, erase *.* works much slower than >when command.com is used. I tested this by erasing 100 files using each. >I did this on an otherwise empty hard disk partition. The result: >- using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds >- using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. > >The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. > >A bug or a feature? Any explanations? I have noticed the same with xtree/pro/gold/etc. I think the reason is that xtgold and 4dos probably delete a file at a time whereas I think all DOS does is read in the directory cluster into memory, wipe it and resave it. You might find that del *.exe when there are lots of exe's might take longer than del *.* in DOS. (I might also be wrong :-) |/ |\evin
stoeen@solan.unit.no (Asbj|rn St|en) (05/20/91)
In article <1991May20.064529.1764@nic.funet.fi>, akoivuma@finsun.csc.fi (Antti Koivumaki) writes: |> I have noticed that when I use 4dos.com, erase *.* works much slower than |> when command.com is used. I tested this by erasing 100 files using each. |> I did this on an otherwise empty hard disk partition. The result: |> - using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds |> - using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. |> |> A bug or a feature? Any explanations? Perhaps this is the explanation: COMMAND.COM uses FCB (file control block) commands when it erases files. This erase command can handle wildcards such as '*'. 4DOS.COM uses the ASCIIZ erase command, which does not handle wildcards. This means that 4dos has to find each file, then erase them one by one. Why does 4dos use the slower version? By using ASCIIZ commands it is easier to implement a 'prompt' facility for each file. Besides, the ASCIIZ erase command can take a complete path specification, while the FCB function only works on the current directory. This means that the file specification has to be parsed, the current directory has to be changed, erase files, then switch back to the previous directory. The FCB function is much more tedious. Hope this was clear enough... -- _ Asbjoern Stoeen / \ /___ Studpost 188 /___\ // 7034 Trondheim-NTH / \ / \__ Norway / \ (stoeen@solan.unit.no) / ___/
ralphs@seattleu.edu (Ralph Sims) (05/20/91)
komarimf@spiff.soe.clarkson.edu (Mark Komarinski) writes: > akoivuma@finsun.csc.fi (Antti Koivumaki) writes: > >I have noticed that when I use 4dos.com, erase *.* works much slower than > >when command.com is used. I tested this by erasing 100 files using each. > >A bug or a feature? Any explanations? > I think it's a combination of both. From your findings, I'd have to assume > 4dos expands the *.* before deleting and then performs a separate delete for It may have to do this in conjunction with its other options (confirm a file deletion or to force a 'y' response to deleting an entire directory). The DIR command is also slightly different from OtherDOS, and takes longer. The ability to attach file descriptions may also force a different internal search routine. 4DOS does more, and that may be the reason it takes a tad longer on some functions--it's a minor thing, considering everything it DOES do. -- The 23:00 News and Mail Service - +1 206 292 9048 - Seattle, WA USA PEP, V.32, V.42 +++ A Waffle Iron, Model 1.64 +++
dahlstr@hus.chalmers.se (Gunnar Dahlstrom) (05/21/91)
In article <1991May20.064529.1764@nic.funet.fi> akoivuma@finsun.csc.fi (Antti Koivumaki) writes: >I have noticed that when I use 4dos.com, erase *.* works much slower than >when command.com is used. I tested this by erasing 100 files using each. >I did this on an otherwise empty hard disk partition. The result: >- using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds >- using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. With filehandels you can only delete 1 file. So if you write del *.* 4dos make a list of all files and execute delete <filename> for every fil there is. But if you use FCB (wich Microsoft official not support (its a old way to handle files) but they use it in command.com) you can execute a del *.* if you use FCB to handels wit your files! // Gunnar =============================================================================== Gunnar Dahlstrom Chalmers University of Technology Div. Building Technology 412 96 Gothenburg, Sweden E-Mail: dahlstr@hus.chalmers.se or dahlstr@htpc2.hus.chalmers.se ===============================================================================
bytehead@bluemoon.uucp (Bryan Price) (05/21/91)
ins845b@monu4.cc.monash.edu.au (mr k.l. lentin) writes: > In article <1991May20.064529.1764@nic.funet.fi> akoivuma@finsun.csc.fi (Antti ...stuff deleted... > I have noticed the same with xtree/pro/gold/etc. I think the reason is that > xtgold and 4dos probably delete a file at a time whereas I think all DOS does > might find that del *.exe when there are lots of exe's might take longer than > del *.* in DOS. (I might also be wrong :-) Nope. DOS (COMMAND.COM) uses FCB's to do the deleting. If you use the ASCIIZ function calls, you MUST call dosfindfirst, dosfindnext to get each file and then delete them (It is faster to read the filenames first and then delete them, I've timed it...) With FCBs you just use the wild-cards and voila, all the files are deleted. Of course that means that you can't delete selectively, or make sure you can delete it by chaning it's attributes. My version of rm is just as fast as DOS on a local drive and under 100 files. On a network or over 100 files, DOS beats it hands down. I can delete 600 files in 2.2 seconds with DOS. It takes 1.5 minutes with my rm. Curious, DOS 5.0 supports a /P parameter for prompting of each file name for deletion.... The damn thing is probably still using FCBs though... (I've got to get a .sig file together... I find the default hideous!) > > |/ > |\evin This is from bytehead@bluemoon.uucp bytehead%bluemoon@nstar.rn.com who doesn't have their own obnoxious signature yet
mshiels@tmsoft (Michael A. Shiels) (05/21/91)
This symtom you are seeing is the difference between using DOS 1-2 and DOS 3 calls. The old FCB DOS 1-2 calls take wildcards while the newer DOS 3 handle related type calls only take one filename without wildcards. Makes for a
roy%cybrspc@cs.umn.edu (Roy M. Silvernail) (05/21/91)
akoivuma@finsun.csc.fi (Antti Koivumaki) writes: > I have noticed that when I use 4dos.com, erase *.* works much slower than > when command.com is used. [...] > - using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds > - using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. > > The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. > > A bug or a feature? Any explanations? A difference, I think. 4dos appears to do 100 deletes, where command.com invokes some of the DOS magic dust and just kills the directory entries and frees all the clusters en masse. That, though, is the _only_ point on which command.com can win against 4dos. Things could be worse; you could be doing 100 deletes through the NewSpace compressing disk driver... at about 2-3 deletes per second. -- Roy M. Silvernail -- roy%cybrspc@cs.umn.edu - OR- cybrspc!roy@cs.umn.edu perl -e '$x = 1/20; print "Just my \$$x! (adjusted for inflation)\n"' [space reserved for clever quote]{mail your submissions}
traub@rtf.bt.co.uk (Michael Traub) (05/21/91)
In article <s47922w164w@halcyon.uucp> halcyon!ralphs@seattleu.edu (Ralph Sims) writes: >komarimf@spiff.soe.clarkson.edu (Mark Komarinski) writes: > >> akoivuma@finsun.csc.fi (Antti Koivumaki) writes: > >> >I have noticed that when I use 4dos.com, erase *.* works much slower than >> >when command.com is used. I tested this by erasing 100 files using each. > >It may have to do this in conjunction with its other options (confirm a file >deletion or to force a 'y' response to deleting an entire directory). The >DIR command is also slightly different from OtherDOS, and takes longer. >The ability to attach file descriptions may also force a different internal >search routine. 4DOS does more, and that may be the reason it takes a >tad longer on some functions--it's a minor thing, considering everything >it DOES do. Actually I think you'll find that Command.Com uses the old style FCBS while 4DOS doesn't and that is the main cause of the perceived slowness. Michael Traub BT Customer Systems, Brighton Systems Centre. traub@rtf.bt.co.uk
ericb@eecs.cs.pdx.edu (Eric Berggren) (05/21/91)
akoivuma@finsun.csc.fi (Antti Koivumaki) writes: >I have noticed that when I use 4dos.com, erase *.* works much slower than >when command.com is used. I tested this by erasing 100 files using each. >I did this on an otherwise empty hard disk partition. The result: >- using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds >- using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. >The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. I have noticed a similar problem. So here's MY theory. Everytime 4DOS deletes a file, it goes through the whole routine to get the path and print it out. Even with the /q option, it may still be going through the same mess. I set up the alias "deldir command /c del %1" when I want to do some "serious" kills. (CP/M lives!) -e.b. ============================================================================== Eric Berggren | "Life is a Turing Test; Computer Science/Eng. | We're all automatons!" ericb@eecs.cs.pdx.edu | - (click, whir, buzz, chirp)
traub@rtf.bt.co.uk (Michael Traub) (05/21/91)
In article <1991May20.143142.16378@monu0.cc.monash.edu.au> ins845b@monu4.cc.monash.edu.au (mr k.l. lentin) writes: >In article <1991May20.064529.1764@nic.funet.fi> akoivuma@finsun.csc.fi (Antti Koivumaki) writes: >>I have noticed that when I use 4dos.com, erase *.* works much slower than >>when command.com is used. I tested this by erasing 100 files using each. >>I did this on an otherwise empty hard disk partition. The result: >>- using 4dos.com (v. 4.02), erase/q *.* takes about 5 seconds >>- using command.com (of DOS 3.3), erase *.* takes less than 0.5 seconds. >> >>The computer is a 12 MHz AT with a 40 MB Seagate ST251 hard disk. >> >>A bug or a feature? Any explanations? > >I have noticed the same with xtree/pro/gold/etc. I think the reason is that >xtgold and 4dos probably delete a file at a time whereas I think all DOS does is read in the directory cluster into memory, wipe it and resave it. You >might find that del *.exe when there are lots of exe's might take longer than >del *.* in DOS. (I might also be wrong :-) > >|/ >|\evin No WAY!!! Command.Com uses MS-DOS to do all its work and doesn't do anything as nasty as you suggest. Michael Traub BT Customer Systems, Brighton Systems Centre. traub@rtf.bt.co.uk
toma@sail.LABS.TEK.COM (Tom Almy) (05/21/91)
Just a suggestion if you want a quick erase while running 4dos: alias qe*rase command /c erase -- Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply
warnock@stars.gsfc.nasa.gov (Archie Warnock) (05/21/91)
In article <mHy021w164w@bluemoon.uucp>, bytehead@bluemoon.uucp (Bryan Price) writes... >Nope. DOS (COMMAND.COM) uses FCB's to do the deleting. If you use the And it's probably worth noting that Microshaft specifically warns developers _against_ continuing to use FCBs for such things, since file handles are now the "officially recognized" way of doing such things. The moral is, if you do what MS claims you have to do to be compatible, people will complain that the performance isn't good enough. Anyone still wondering why the FTC is investigating Microsoft? ---------------------------------------------------------------------------- -- Archie Warnock Internet: warnock@stars.gsfc.nasa.gov -- ST Systems Corp. SPAN: STARS::WARNOCK -- NASA/GSFC "Unix - JCL for the 90s"
warnock@stars.gsfc.nasa.gov (Archie Warnock) (05/22/91)
In article <1991May21.074445.14677@rtf.bt.co.uk>, traub@rtf.bt.co.uk (Michael Traub) writes... >Actually I think you'll find that Command.Com uses the old style FCBS >while 4DOS doesn't and that is the main cause of the perceived slowness. Correct - this was confirmed by the 4DOS authors on one of the PC-based nets. If I recall correctly, they also said a future release will include some sort of "fast delete" command. ---------------------------------------------------------------------------- -- Archie Warnock Internet: warnock@stars.gsfc.nasa.gov -- ST Systems Corp. SPAN: STARS::WARNOCK -- NASA/GSFC "Unix - JCL for the 90s"