X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,TW_CG X-Spam-Check-By: sourceware.org Message-ID: <3e610509cb846e12307dfc94c646f445.squirrel@www.webmail.wingert.org> In-Reply-To: <4C094B0D.5010406@cs.umass.edu> References: <4C03D6C5.4050004@x-ray.at> <80373222dd5d43b134a5ede7036e7674.squirrel@www.webmail.wingert.org> <20100602080626.GV16885@calimero.vinschen.de> <383c8b44a088dad09a0b77d3299feda7.squirrel@www.webmail.wingert.org> <20100602174848.GA14172@ednor.casa.cgf.cx> <20100603235944.GA12167@ednor.casa.cgf.cx> <20100604024422.GB12167@ednor.casa.cgf.cx> <78e7b77657c0cfcd63dc22ad9679bc85.squirrel@www.webmail.wingert.org> <20100604045807.GC12167@ednor.casa.cgf.cx> <2570318aabfa537bf24c8d3a55f9dcd4.squirrel@www.webmail.wingert.org> <4C092F96.5040800@cygwin.com> <7a1785a5f0a1d0a8956cd10e573f2e53.squirrel@www.webmail.wingert.org> <4C094B0D.5010406@cs.umass.edu> Date: Fri, 4 Jun 2010 14:14:32 -0700 Subject: Re: Cygwin Performance and stat() From: "Christopher Wingert" To: cygwin@cygwin.com User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Agreed, I would like to make a global change, however, unless I can talk to the current maintainer of the fhandler* functions, it seems illogical for me to change them (as I have about a week of cygwin dll experience). Also my interest in performance is limited to a very certain subset of executables : bash, rsync, stat, and du. As an example find already seems to have good performance under cygwin. > I don't think there's an objection here to > patching *rsync* specially in the cygwin > environment -- that would be between you > and the rsync port maintainer. The issue > is whether or not to make a more general > change to cygwin itself, and cgf is just > saying that that's hard to do. > > Conceivably we could come up with some > additional functions that cygwin ports > could use if they want to, but "out of > box" use of stat needs to replicate > full behavior since there's no way to > know what a given call of stat really > needs ... > > Eliot Moss > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple