Mail Archives: cygwin/1997/04/11/15:04:46
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.
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.
- Jonathan Lanier
jonathan AT westwood DOT com
-
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".
- Raw text -