Here-Scripts in bash (fwd)
Sat Apr 12 12:20:00 GMT 1997
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
> 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.
<J Q B>
For help on using this list (especially unsubscribing), send a message to
"firstname.lastname@example.org" with one line of text: "help".
More information about the Cygwin