Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Sun, 10 Jun 2001 23:51:31 -0400 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: Recent changes to path_conv::check -- ouch Message-ID: <20010610235131.A10749@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20010610201750 DOT A8503 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i In-Reply-To: <20010610201750.A8503@redhat.com>; from cgf@redhat.com on Sun, Jun 10, 2001 at 08:17:50PM -0400 [following up on myself] Kazuhiro's patch has forced me to look into this function a little more. It looks like we're just calling rootdir repeatedly rather than invoking the OS. I guess that is ok. I'd rather not have even that perfomance penalty but I don't know if it can be avoided. cgf On Sun, Jun 10, 2001 at 08:17:50PM -0400, Christopher Faylor wrote: >Egor, >I guess I missed this before but you added a potentially expensive >operation to the middle of the path_conv check loop by calling >update_fs_info repeatedly. This looks like we will suffer a performance >hit in the non-ntea case for the privilege of a performance gain for the >use of ntea for symlinks. I don't think that's acceptable. > >It also looks like even in the ideal case, we're guaranteed to call >update_fs_info twice on the same path. > >Also, you seemed to have changed the name of some recently added >elements to the path_conv class. vol_flags became fs_flags and >vol_serial became fs_serial. > >path_conv is probably the most frequently called function in cygwin so >we've tried very hard to keep the code flow as optimized as possible by >not calling the OS too often. Maybe I'm wrong, but I think you've >probably added a performance hit with your recent changes. > >Have you run any before/after performance checks on your code?