Re: Here-Scripts in bash (fwd)

[Jim Balter <jqb at netcom 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.

--
<J Q B>
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".