From: jqb AT netcom DOT com (Jim Balter) Subject: Re: Here-Scripts in bash (fwd) 12 Apr 1997 19:19:33 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <334EC7C0.3163.cygnus.gnu-win32@netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: Jonathan Lanier Original-CC: Win32 Mailing List Original-Sender: owner-gnu-win32 AT cygnus DOT com Jonathan Lanier wrote: > > My 2 cents: > > > on average. In contemporary PCs, assuming an average of 2 cycles per > > instruction, a 166MHz pentium can execute about 250 instructions > > in 3 microseconds. In an application that does creation/destruction > > of temp files all the time or for every transaction, it is > > just not something that one would say is elegant to be inserted > > into the loops. > > Er, what about the tens (possibly hundreds) of thousands of instructions > that occur just from calling the OS file open API function? And the > overhead for reading/writing disk sectors? Seems to me that 3 > microseconds is trivial enough to be close to zero, for all practical > assumptions. The argument falls apart in both cases: > > 1) You don't make very many temp files. Overhead is therefore not important. > 2) You DO make lots of temp file very frequently, in which case the OS > overhead for file creation/deletion is WAY worse than an environment > lookup (less than 0.1%). So overhead is still not important. > > First important rule of code optimization is only optimize the inner > loop: i.e. don't waste time (and code portability) to save cycles when > they won't be visible. It seems from something Mr. Chin is thinking that you would try /tmp first, then try $TEMP if /tmp wasn't found, which would indeed cost an extra open attempt per temp file. This *still* isn't very expensive, at least not on Win NT, because the contents of / will be cached. But this isn't the right order to do things; you generally want environment variables to override defaults. Also, it has already been suggested that, if /tmp is needed but doesn't exist, it should be created. Since this would only be done once, it has asymptotically zero cost. I still can't make any sense of his 6502 comment; it made *more* sense, not less, to worry about cycles on a 6502. I started programming on an IBM 1620 where a branch took 200 microseconds and adds were 20 microseconds per digit plus overhead. I paid a whole lot of attention to cycle times back then, but sufficient quantitative changes in costs call for qualitative changes in methodology. > Personally, I think since the TEMP variable is a standard on the Win32 > platform, that the GNU tools should adhere to that standard when they are > being compiled to run natively on that platform. I find the need for 2 > temp directories quite annoying. Also what if I don't want to use C: for > my temp directory? What if I have a separate partition, on a faster hard > drive, and I want all my temp files placed there instead? I can think of > no logical reason for NOT using the TEMP environment variable. It just > makes sense. As long as we are talking about Win32, temp files should be created with the FILE_ATTRIBUTE_TEMPORARY flag to minimize flushes to the disk. Then it wouldn't matter where you create the file if you have enough main memory to hold it. -- - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".