This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Performance problems


On Mon, Jun 06, 2005 at 06:51:46PM -0700, Linda W wrote:
>><And as soon as you start timing out your cache, you either have a
>>separate thread running which manages this (which implies careful
>>attention to locking issues and context switching) or you a schedule
>> timer signal (which has similar problems).)
>> 
>>
>This may not be necessary if you only cache file handles within
>1 execution of a program (like find), so that file-ops within the same 
>program achive speedup.  You could time-out cache entries on an
>as-needed basis or timer.

Let me say it again.  You can't keep files open for an arbitrarily long
time.  That means that you need some method to invalidate entries in the
cache.  That means another thread running to sweep the cache.  That means
locking and added complexity.

>>I was filling in the details here just to show that the solution of
>>keeping files open has consequences.  Keeping the file open increases
>>the complexity of every function which manipulates a file rather than
>>the one or two functions which might be interested in the cached status
>>information.
>>
>True...but ideally we are only talking about caching & leaving open
>file desriptors within 1 or 2 clockticks -- within the same program.
>If another cygwin program requests deletion of the file, schedule it
>for deletion when it becomes uncached.

It doesn't matter how long the handles are open.  Any cygwin function
that deals with files would have to be aware that the handle was open.

>Sure, I'm sure you and I both can come up with infinite ways that
>it might be implemented in a broken manner.  I guess I'm
>operating under the assumption that it would be done correctly --
>with the ability to turn it on/off via a CYGWIN var or such,
>while it is being developed. 

I wasn't talking about anything being "broken".  I was talking about
increasing complexity in cygwin and the fact that this isn't a simple
problem and that you can't just say "It will speed things by X because
we're removing all of these extra calls to stat() (or whatever)".

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]