Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3F95B7DE.90601@tlinx.org> Date: Tue, 21 Oct 2003 15:49:02 -0700 From: "Linda W." Organization: what's organization? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en-ca, en-gb, en-nz, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin performance References: <3F957E0D DOT 2060405 AT tlinx DOT org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Igor Pechtchanski wrote >I suspect you're not comparing apples to apples here. Later Windows >versions run a file indexing service in the background, which makes >finding files faster. You might get more relevant results if you tried >using "locate" after an "updatedb". > > --- Nope...apples to apples....have indexing serviced turned off. I know how fast locate is after it has used 'find' to generate updatedb. The find command to generate that db takes over an hour (indexes a few directories on net servers as well), but even a local-only search can take quite a while. > > >>Even using 'perl' over combo's of cat|tr|sed|grep|more is significantly >>faster to almost make the old unix standard scripting commands near >>worthless (I've gotten more efficient at 1-line perl scripts ala (perl >>-e '....'). >> >> > >You can always run these things under strace to see where the time goes. >Many factors enter into these slowdowns, e.g., if your Cygwin is installed >on a network drive, spawning multiple programs is likely to be much slower >than spawning one, no matter how large. > > ---- Not on network drive....all on same drive. Hmm...didn't strace was around...but I'm using "sysinternals" 'filemon" which returns all calls to the underlying OS. Dunno, but am guessing strace is tracing the "cygwin" "system" calls, not the underlying Win-OS calls. in which case it isn't a good tool to use, since a single open in the 'cygwin-os' could map to several "opens" on the NT layer to emulate some 'dynamic' that exists in unix but not windows. Sysinternals site also has toosl for monitoring all registry accesses, tcp open ports and connected, calls to network api layer, and a "top" "ProcEXP" tool that allows one to see what DLL modules are loaded for a process, see where each thread is executing and determine cpu time used/thread -- as well as allowing inspection of all handles opened by a process and (don't try this lightly) forcing close a handle (on win2k and above). But just look at 'filemon' output on 'find' vs. ms find. ms.find just looks at directory entries -- while 'find' opens each file. Why it does this to determine if a file name exists is a bit obscure. >>Perhaps it is unavoidable, but I see things like find doing 2 'opens' / >>file when it is searching for files...can't it just do a 'stat' of some >>nature? does it need to do an open, let alone 2? >> >> > >Which tool do you use see this? FWIW, I see at least one ReadFile in the >Cygwin fstat implementation (fstat_helper in fhandler_disk_file.cc), for >reading magic numbers to determine the executable bit. > > ---- Looking at tool that monitors NT/Win32 system calls, not cygwin callls. It's the overall efficiency of cygwin tools on top of the cygwin layer I'm looking at, not the efficiency of any specific gnu program as implemented on top of a linux/cygwin layer. -linda > > >>Just wondering.... >>tnx, >>-linda >> >> > >As always, PTC. > Igor > > -- ---> A software Engineer for CA governer? <--- ---> Georgy Russell for CA governor <--- ---> http://www.georgyforgov.com <--- -- 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/