[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cygwin-patches
Subject:    Re: access () and path.cc
From:       "Pierre A. Humblet" <Pierre.Humblet () ieee ! org>
Date:       2003-02-28 6:20:54
[Download RAW message or body]

At 01:10 AM 2/28/2003 -0500, Christopher Faylor wrote:
>On Fri, Feb 28, 2003 at 01:02:58AM -0500, Pierre A. Humblet wrote:
>>At 12:56 AM 2/28/2003 -0500, you wrote:
>>>On Fri, Feb 28, 2003 at 12:49:59AM -0500, Pierre A. Humblet wrote:
>>>>OK, following Chris' remarks here is a much smaller set
>>>>of changes.
>>>
>>>Do you think it would make sense to do something along the lines
>>>of:
>>>>+      path_conv pc (cfd->is_device ? cfd->get_name () :
>>cfd->get_win32_name (), PC_SYM_NOFOLLOW);
>>
>>I guess one could but judging from the times I see in 
>>strace it's not really justified.
>>
>>On the other hand that's something that we could look at after you
>>integrate your code.  There could eventually be a single get_name
>>returning what's appropriate.
>
>This isn't an issue with my code, at least for fstat64.  That's one of
>the reasons for my changes.  I was trying to minimize the number of
>duplicate passes through path_conv::check.  I still have some tweaking
>to do though since adding path_conv to fhandler balloons the sizes of
>fhandler_base and ends up using a lot more space in cygheap, which means
>more memory to copy on fork, which could mean slower forks, which means
>that my performance improvement makes things work more slowly...

Right. The funny part with path_conv is that 2/3 of the storage is in 
fs_info. Is that really needed/useful?

>Anyway, please feel free to check in what you have.

OK, this evening.

Pierre

[prev in list] [next in list] [prev in thread] [next in thread]