On Fri, Jul 22, 2005 at 12:28:08PM +0200, Vaclav Haisman wrote: >On Thu, 21 Jul 2005, Christopher Faylor wrote: >>On Fri, Jul 22, 2005 at 03:17:33AM +0200, Vaclav Haisman wrote: >>>On Thu, 21 Jul 2005, Christopher Faylor wrote: >>>>On Fri, Jul 22, 2005 at 01:32:50AM +0200, Vaclav Haisman wrote: >>>>>the attached patch sets FILE_ATTRIBUTE_TEMPORARY on files opened by >>>>>mkstemp() on WinNT class systems. Theoretically the OS should then be >>>>>less eager to write such files onto the physical storage and use cache >>>>>instead. >>>> >>>>Thank you for the patch but unless you can demonstrate some obvious >>>>performance improvements I don't think we'll be applying it. You've >>>>slowed down (slightly) the common case of calling open for the uncommon >>>>case of calling mk?temp. >>> >>>I am not sure what kind of slow down do you mean. Is it the one extra >>>call? >> >>It was more than one extra call, but yes. >> >>>In that case the attached modified patch should fix it. The call to >>>open_with_attributes() in open() gets inlined, I have checked the >>>resulting .s file. >> >>Can you demonstrate some obvious performance improvements? Does it >>speed up configure, make bash start up faster, make the rxvt window >>faster to show up? > >I don't think that any of the extra ifs and assignments could cause any >measurable slowdown. I also do not think that there are any _obvious_ >speed ups. It is merely a hint to the cache subsystem, not a silver >bullet.
I wasn't asking if there was a slowdown. I wanted to know the rationale for this change. Increasing code complexity for no obvious gain is not something that I want to do. cgf