[<<]Message[>>] [<<]Author[>>] [<<]Subject [<<]Thread
Number : 189 Date : 2001-06-13 Author : Kan Yabumoto Subject : Re: XXCOPY efficiency questions Size(KB) : 7
1. Gabe's suggestion (question?) was a good one. When you have an embedded space, you could substitute the space with a "?". Although this adds slight uncertainty, it should work for most similar occasions. xxcopy "c:\program files\napster\..." ... You could say xxcopy c:\program?files\napster\..." ... Here, the "?" between the words program and files makes it a contiguous string which does not need the surrounding double quotes. And, luckily, XXCOPY's "Wild-wild-source" feature which allows wildcards at any place any number of times makes this trick work. To answer the question of efficiency, the presence of wildcard forces XXCOPY to do more work and less efficient. 2. The efficiency between /EX and /X are the same (after the initial evaluation of the parameters is done, the operation becomes identical in the actual traversing of the subdirectories). This is due to the fact XXCOPY employs an optimization step where redundant exclusion specifiers are removed, all syntactic error conditions are removed, etc. As long as the same set of exclusion items are entered, regardless of where they are entered (/EX vs /X), the result will be the same (see below for more on this). 3. Same as Item 2. The two expressions, .\*.pst and *.pst will be evaluated to an identical pattern before they are further optimized. 4. /Q will speed up by not wasting time on the display. The display and the file-copying is not 100% overlapped. However, the underlying disk I/O caching makes the actual hard disk activities and program execution mostly overlapped anyway --- the effect is not as straightforward (and makes it harder to quantify the effect of using /Q). The best way to tell is simply to run some experiments for yourself. 5. /AO (which Gabe probably meant /OA) has the same effect as /Q. Any extra work will have some added CPU usage, etc. 6. logging.. Again, the same. --------------------------------------------------------------------------- OK, it's Gabe's fault. Here we go again with today's babbling... Gabe's concern was the "efficiency". A few people talk about the subject anymore, except the device driver writers and compiler writers and of course, video game programmers. I was a professional video game programmer. The company name, Pixelab still carries some of my background... But, in general, the program efficiency is something most people should not worry. I'm not saying you should be totally ignorant about it. The more you are aware of what is going on inside the computer, you can see things better and make things run faster. No question about it. But, let me just say one word about it. When it comes to XXCOPY, the program itself works hard to make sure things are running relatively efficiently. Not much the user can do. Of course, whether you generate a huge log output (now you have a very precise control of how much log output you want XXCOPY to generate) or not will have a substantial impact to the performance. If you have an old 486 with a very poor (say, you have a std VGA) video card, and running the classic Windows 95 (newer Win9x may not even run on a 486-33MHz), yes, even /Q will have a substantial impact on the performance since the video scrolling will be a very slow process on such a machine. But, most users now have Pentium 2 or better and 300 MHz or faster with AGP video which is extremely fast on character-based display. I'm not sure even with or without /Q, you can measure the difference in time. At any rate, nearly all of the performance questions one can have may be tested and empirically determined. XXCOPY's performance statistics at the end will help you compare different cases easily. (Of course, when you repeat the same set of copy jobs, you get different results every time --- disk-caching and other factors cloud the issue). In one word, I would not worry too much. On the exclusion items, let me add this (if you care the details) In microscopic view, the order of entries of exclusion parameters may have an intricate influence on the performance. Since XXCOPY does not perform rearrangements (such as alphabetizing), the order of user-entry in the multiple-exclusion item specifying will influence on how they are stored inside XXCOPY and utilized later. Since the run-time evaluation of exclusion items is terminated as soon as the current object (directory or a file) qualifies for an exclusion, XXCOPY stops the checking at the spot. Therefore, the order of the exclusion items that you specify becomes a factor. In general, you should specify a more "global" item earlier. Also, if you know the native order of the items to be excluded inside of your source directory, it is faster if an item to be excluded earlier is specified earlier in the list. This is because the earlier one, once encountered (and not to be found again) will be dynamically removed from the exclusion list. In other words, the more exclusions XXCOPY handles, the shorter the remaining list becomes, because of less performance penalty of having less number of the exclusion items to go through. Let me reveal that my background in programming is the video game programming in assembler. I wrote the arcade video game, Mad Planets (Gottlieb Co. For details, http://members.aol.com/jpmlee/qbert.htm) That was with the naked 5MHz 8088 CPU with 24KB ROM which was the entire program. The 5MHz 8088 had 800 nsec instruction fetch (and each instruction took a few of the instruction cycles). The video game demanded 60 Hz screen-refresh which forced the program to compute everything in 16.7 msec which had only several thousand instructions to run per frame!!! So, I was there when every clock cycle was counted. I still do pay attention to program efficiency. Of course, once the monstrous OS like Win9x is written in C, there is no point fooling around in assembler for a program like XXCOPY. On the other hand, XXCOPY may not be the fastest copy program on the planet. It may well be that ROBOCOPY beats XXCOPY by a noticeable margin (I don't even know if that is the case). At this point, our emphasis on XXCOPY is not the speed. It is the right combination of features to save greater time for the users. (And when I saw a potential performance bottleneck with hundreds of /X items being specified for a big job, the optimizer was put in place before anybody asked for it. --- while most users would not notice it, I'm quite satisfied with the fact that lots of clever tricks were implemented so that a huge set of /X items would not noticeably slow down the XXCOPY performance --- I would like to see a side- by-side comparison between XXCOPY and similar utilities with exclusion features. Anyway, being clever is much more important than being single-mindedly faster. Kan Yabumoto ====================================================================== At 2001-06-13 13:06, Gabe Fineman wrote: >When writing batch files to use xxcopy, are there things to do to >increase efficiency? For example: > >1. is it better to use \"Local Settings"\ rather than \Local?Settings\ >2. is it better to use an exclusion list (/EX) or multiple /X statements >3. is it better to use /X.\*.pst instead of /X*.pst >4. does using any of the /Q switches speed things up >5. does logging (/AO) slow things down >6. does dos logging (xxcopy > big.log) slow things down > >What switches (or switch combinations) should be avoided to speed >things up? > >-Gabe Fineman
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.