On Thu, Jul 01, 2010 at 11:50:01AM -0400, "Marc-Andr? H?bert" wrote:
>Hello,
>
>I installed cygwin a few weeks ago and it has always been very slow.
>At first I only needed to perform a few tests (I usually work using a
>linux VM) so I didn't look too much into it, but now I might need to
>use it m
On 7/1/2010 11:50 AM, Marc-André Hébert wrote:
Hello,
I installed cygwin a few weeks ago and it has always been very slow.
At first I only needed to perform a few tests (I usually work using a
linux VM) so I didn't look too much into it, but now I might need to
use it more and it is simply not u
On Jun 6 19:28, Christopher Faylor wrote:
> On Mon, Jun 07, 2010 at 12:12:36AM +0200, Matthias Andree wrote:
> >Meaning that: even if I'm only a Cygwin user, and I'm sometimes
> >disappointed by how slow it is, too, I'm sort of convinced there isn't a
> >cheaper way to get all the required inf
On Jun 5 08:43, Christopher Wingert wrote:
> So... the person who cared to improve his/her/its code would say, "Well
> we use NTOpenFile() because it does the blah blah extra functionality that
> FindNextFile()/GetFileAttributes() do not." Then we could look to other
> Win32 APIs to try to achie
On Mon, Jun 07, 2010 at 12:12:36AM +0200, Matthias Andree wrote:
>Meaning that: even if I'm only a Cygwin user, and I'm sometimes
>disappointed by how slow it is, too, I'm sort of convinced there isn't a
>cheaper way to get all the required information.
I'm disappointed in Cygwin's slowness to
Am 06.06.2010, 01:16 Uhr, schrieb Christopher Wingert:
I do think out loud with my "team". You are not on it.
Agreed! You would rather spend your time ridiculing any possible
solution.
If only there had been a solution, rather than a loose collection of names
(I wouldn't even dare call
Dave Korn writes:
> On 04/06/2010 18:33, Christopher Wingert wrote:
>>> [quit top-posting]
>>
>> Now you are my mom too?
>
> No, I am. Now quit playing with all your new friends and
> dinner!
>
> cheers,
> Your Mom
OK. I'm a Chinese, and I'm laughing out loud with this one.
http:/
On Sat, Jun 05, 2010 at 04:16:42PM -0700, Christopher Wingert wrote:
>>I do think out loud with my "team". You are not on it.
>
>Agreed! You would rather spend your time ridiculing any possible
>solution.
>
>This is what lead to my initial reluctance to do any patch for Cygwin
>software.
>
>Good L
On 04/06/2010 18:33, Christopher Wingert wrote:
>> [quit top-posting]
>
> Now you are my mom too?
No, I am. Now quit playing with all your new friends and get home for your
dinner!
cheers,
Your Mom
--
Problem reports: http://cygwin.com/problems.html
FAQ: h
> I do think out loud with my "team". You are not on it.
Agreed! You would rather spend your time ridiculing any possible solution.
This is what lead to my initial reluctance to do any patch for Cygwin
software.
Good Luck with your inferior product.
Chris
--
Problem reports: http://
On Sat, Jun 05, 2010 at 08:43:50AM -0700, Christopher Wingert wrote:
>On Sat, 5 Jun 2010 01:24:29 -0400 Christopher Faylor wrote:
>>On 06/04/2010 03:14 PM, Christopher Wingert wrote:
>>>He is? Holy crap, he is more helpful with his sarcasm and doubt than
>>>anything else.
>>
>> Can't really parse
> Can't really parse that sentence.
Then load your English parser.
> I haven't detected any "picking on" but then I can't claim to have
> written the fhandler* code anymore Corinna has rewritten most of it. I
> do know that if you want to be taken seriously you really need to send a
> concrete
On Sat, Jun 05, 2010 at 01:24:29AM -0400, Christopher Faylor wrote:
>
>On Fri, Jun 04, 2010 at 02:37:01PM -0700, Christopher Wingert wrote:
>>On Fri, Jun 04, 2010 at 03:16:43PM -0600, Eric Blake wrote:
>>>On 06/04/2010 03:14 PM, Christopher Wingert wrote:
Agreed, I would like to make a global c
On Fri, Jun 04, 2010 at 02:37:01PM -0700, Christopher Wingert wrote:
>On Fri, Jun 04, 2010 at 03:16:43PM -0600, Eric Blake wrote:
>>On 06/04/2010 03:14 PM, Christopher Wingert wrote:
>>>Agreed, I would like to make a global change, however, unless I can
>>>talk to the current maintainer of the fha
He is? Holy crap, he is more helpful with his sarcasm and doubt than
anything else. However, it does explains his tone, given that I am
picking on his code.
I see your reference to an acronym regarding top posting, but not a
policy. In fact your reference is specifically listed under another
ob
On 06/04/2010 03:14 PM, Christopher Wingert wrote:
> 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).
You ARE talking to the
See further down the thread, the right solution is to impact ALL cygwin
executables, but I don't have the experience in the dll to make those
changes.
> On 6/4/2010 2:20 PM, Christopher Faylor wrote:
>>> "But providing a variant of stat() along the lines of what you propose
>>> above is not pract
I actually wrote my own rsync in AutoIt, but it is also limited.
However, I thought it would a nice addition to speed up Cygwin. As I have
been using it for about 10 years and made my transition from Linux to
Windows so pleasant.
> On 4 June 2010 19:50, Eliot Moss wrote:
>> I don't think there'
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
executab
On 4 June 2010 19:50, Eliot Moss wrote:
> 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
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 cou
On 6/4/2010 2:20 PM, Christopher Faylor wrote:
"But providing a variant of stat() along the lines of what you propose
above is not practical for all the reasons already stated."
This is not something that I said. That was actually Larry Hall.
Heh. Who needs him anyway!
Just to clarify, this
On Fri, Jun 04, 2010 at 10:33:47AM -0700, Christopher Wingert wrote:
>Eric Blake wrote:
>> [quit top-posting]
>
>Now you are my mom too?
"too?" I don't recall any other responses from Eric to you.
>> That's where you're wrong. Any patch you write that is technically
>> sound and shows a measura
On Fri, Jun 04, 2010 at 10:07:58AM -0700, Christopher Wingert wrote:
>Again, not production, this was to highlight a point and to enhance (I
>would assume) the most common use case (file to file rsync).
>
>Plenty of solutions for a good patch, complete the Windows version of
>stat() or call the Cyg
> [quit top-posting]
Now you are my mom too?
> That's where you're wrong. Any patch you write that is technically
> sound and shows a measurable improvement will most likely be accepted.
Then you shouldn't have Cygwin's front line technical spokesman saying
things such as:
"If there was a way
[quit top-posting]
On 06/04/2010 11:07 AM, Christopher Wingert wrote:
> Again, not production, this was to highlight a point and to enhance (I
> would assume) the most common use case (file to file rsync).
>
> Plenty of solutions for a good patch, complete the Windows version of
> stat() or call
Again, not production, this was to highlight a point and to enhance (I
would assume) the most common use case (file to file rsync).
Plenty of solutions for a good patch, complete the Windows version of
stat() or call the Cygwin version if the Window's version fails.
Since I don't have any confide
On 6/4/2010 12:37 PM, Christopher Wingert wrote:
So here is an example of a performance gain by not using cygwin stat(). I
did this patch in about an hour (with the help of some git code), so I
wouldn't recommend it for any production use.
On a dry run rsync from my local drive to my NAS (105GB
So here is an example of a performance gain by not using cygwin stat(). I
did this patch in about an hour (with the help of some git code), so I
wouldn't recommend it for any production use.
On a dry run rsync from my local drive to my NAS (105GB, 34k files, 4k
directories). The current release
On Thu, Jun 03, 2010 at 07:57:31PM -0700, Christopher Wingert wrote:
>>On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
>>Yeah, that's what I thought you were doing. Given that the timestamps
>>don't indicate "elapsed time of function X", it's not always possible
>>to figure ou
> On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
> Yeah, that's what I thought you were doing. Given that the timestamps
> don't indicate "elapsed time of function X", it's not always possible to
> figure out how long a function takes by subtracting. Subtracting
> timestamps
On Thu, Jun 03, 2010 at 05:32:46PM -0700, Christopher Wingert wrote:
>> On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
>>>Using strace I was able to look at some of the functions that are
>>>enumerated by debugging calls.
>>>
>>>The trace below is done by ls.exe for each file
> On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
>>Using strace I was able to look at some of the functions that are
>>enumerated by debugging calls.
>>
>>The trace below is done by ls.exe for each file (approximately 95k files
>> @
>>88 mSecs/file), approximately 40 mSecs are
On Thu, Jun 03, 2010 at 10:35:55AM -0700, Christopher Wingert wrote:
>Using strace I was able to look at some of the functions that are
>enumerated by debugging calls.
>
>The trace below is done by ls.exe for each file (approximately 95k files @
>88 mSecs/file), approximately 40 mSecs are spent in
Using strace I was able to look at some of the functions that are
enumerated by debugging calls.
The trace below is done by ls.exe for each file (approximately 95k files @
88 mSecs/file), approximately 40 mSecs are spent in lstat64() and another
47 mSecs are spent in getacl().
It also *looks* lik
On Wed, Jun 02, 2010 at 10:46:03AM -0700, Christopher Wingert wrote:
>Thanks for the pointer, I just gave it a whirl, it actually didn't make
>much of a difference.
>
>I am going to start looking into making a patch.
Let me point out that the kind of slowdown that you are seeing is not
something t
Thanks for the pointer, I just gave it a whirl, it actually didn't make
much of a difference.
I am going to start looking into making a patch.
Chris
> On Jun 1 14:42, Christopher Wingert wrote:
>> I think there are a lot of use cases where the extra information (ACL
>> information *I assume*
On Jun 1 14:42, Christopher Wingert wrote:
> I think there are a lot of use cases where the extra information (ACL
> information *I assume* is the majority of the problem) is unnecessary.
> For most of the applications filename, size, and the three dates are all
> that is necessary. So cygwin st
On 6/1/2010 8:06 PM, Christopher Wingert wrote:
That's fine, can you propose something that is acceptable?
Actually no, I'm no visionary here. It's not clear to me how to transparently
determine what fields provided by stat() are used by a particular application.
I suppose that it's possible t
That's fine, can you propose something that is acceptable?
BTW, who does this patch need to pass muster with? The only maintainer I
could find is Dave Korn.
Thanks,
Chris
> On 6/1/2010 5:42 PM, Christopher Wingert wrote:
>> I think there are a lot of use cases where the extra information (ACL
On 6/1/2010 6:18 PM, Larry Hall (Cygwin) wrote:
Thanks for this information and perhaps I'm wrong but I don't believe
anyone in this thread thought that you were lying when you noted issues
with the performance of stat(). ;-) But providing a variant of stat()
along the lines of what you propose
On 6/1/2010 5:42 PM, Christopher Wingert wrote:
I think there are a lot of use cases where the extra information (ACL
information *I assume* is the majority of the problem) is unnecessary.
For most of the applications filename, size, and the three dates are all
that is necessary. So cygwin stat
I think there are a lot of use cases where the extra information (ACL
information *I assume* is the majority of the problem) is unnecessary.
For most of the applications filename, size, and the three dates are all
that is necessary. So cygwin stat is overkill. So if I can tell the
emulation laye
Christopher Wingert schrieb:
I assume POSIX compatibility. However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).
See
http://marc.info/?l=git&m=122278284210941
for an example.
This git do_stat is for only meant f
On Mon, May 31, 2010 at 02:19:52AM +0100, Dave Korn wrote:
>>On Sun, May 30, 2010 at 05:03:46PM -0400, NightStrike wrote:
>>>There's always room for ingenuity and improvements, isn't there?
>
>On 30/05/2010 22:39, Christopher Faylor wrote:
>>If someone is ingenuous enough to make an improvement it'
On 30/05/2010 22:39, Christopher Faylor wrote:
> If someone
> is ingenuous enough to make an improvement it's hard to believe that
> they wouldn't be ingenuous enough to send a patch to cygwin-patches.
No, it isn't. (I'm assuming you meant ingenious rather than ingenuous,
because it doesn't ma
On Sun, May 30, 2010 at 11:52:45PM +0200, Christian Franke wrote:
>Christopher Faylor wrote:
>> On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
>>
>>> I assume POSIX compatibility. However, I bet there are cases where one
>>> can sacrifice compatibility for performance (co
Christopher Faylor wrote:
On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
I assume POSIX compatibility. However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).
The problem is that P
On Sun, May 30, 2010 at 05:03:46PM -0400, NightStrike wrote:
>On Sun, May 30, 2010 at 1:07 PM, Christopher Faylor wrote:
>>On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote:
>>>I was looking into speeding up stat() performance. ?More specifically
>>>bash, ls, test, stat performan
On Sun, May 30, 2010 at 1:07 PM, Christopher Faylor
wrote:
> On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote:
>>I was looking into speeding up stat() performance. More specifically
>>bash, ls, test, stat performance. I've seen the subject come up before.
>>Git recently implem
On Sun, May 30, 2010 at 12:51:31PM -0700, Christopher Wingert wrote:
>I assume POSIX compatibility. However, I bet there are cases where one
>can sacrifice compatibility for performance (configurable with an
>environment flag of course).
>
>See
>
>http://marc.info/?l=git&m=122278284210941
>
>for a
I assume POSIX compatibility. However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).
See
http://marc.info/?l=git&m=122278284210941
for an example.
> On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert w
On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote:
>I was looking into speeding up stat() performance. More specifically
>bash, ls, test, stat performance. I've seen the subject come up before.
>Git recently implemented a native Win32 work around. Are there any cygwin
>patches
I was looking into speeding up stat() performance. More specifically
bash, ls, test, stat performance. I've seen the subject come up before.
Git recently implemented a native Win32 work around. Are there any cygwin
patches around?
Thanks,
Chris
--
Problem reports: http://cygwin.com/pr
Brian,
Thanks for your reply. The Unix test script was
written in ksh.
Dave
--
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/
On Mon, 14 Jun 2004, david.dezan wrote:
> One of the tests was a simple while loop which counted to 100.
Written in what language? Please post.
> This test took approximatly 30 seconds in Cygwin under Citrix and only 4
> seconds in Cygwin on a local machine.
"man strace" and sort on the first
My company is trying to setup a development environment
using Cygwin on a server running Citrix. This allows
multiple users to log into the Citrix server and it
looks to them like they have their own machine.
However, in the course of testing the installation of
our development packages (includin
when I was a college prof I always reminded my students, that there are
no stupid questions, only stupid answers.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Linda W.
> Sent: Wednesday, 22 October, 2003 16:39
> To: [EMAIL PROTEC
Christopher Faylor wrote:
On Tue, Oct 21, 2003 at 11:42:21AM -0700, Linda W. wrote:
Has anyone done any testing on performance of cygwin utils over their
native win counterparts?
Cygwin is slower. Cygwin is known to be slower. And, if you give it
a few minutes of thought it is obvious
Pierre A. Humblet wrote:
Christopher Faylor wrote:
On Wed, Oct 22, 2003 at 09:40:10PM +0200, Hannu E K Nevalainen wrote:
From: Linda W.
Sent: Wednesday, October 22, 2003 12:49 AM
Perhaps it is unavoidable, but I see things like find doing 2
'opens' /file when it is searching for
On Wed, Oct 22, 2003 at 04:41:42PM -0400, Pierre A. Humblet wrote:
>>Although, hmm. I just tried this and bash still executed a file that
>>should be non-executable. I'll have to see why.
>
>bash walks down the PATH looking for anything that matches the name.
>It remembers the first match but kee
Christopher Faylor wrote:
>
> On Wed, Oct 22, 2003 at 09:40:10PM +0200, Hannu E K Nevalainen wrote:
> >> From: Linda W.
> >> Sent: Wednesday, October 22, 2003 12:49 AM
> >
> >> >>Perhaps it is unavoidable, but I see things like find doing 2
> >> >>'opens' /file when it is searching for files...can
On Wed, Oct 22, 2003 at 09:40:10PM +0200, Hannu E K Nevalainen wrote:
>> From: Linda W.
>> Sent: Wednesday, October 22, 2003 12:49 AM
>
>> >>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 natur
> From: Linda W.
> Sent: Wednesday, October 22, 2003 12:49 AM
> >>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?
I believe that the major culp
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
On Tue, Oct 21, 2003 at 11:42:21AM -0700, Linda W. wrote:
>Has anyone done any testing on performance of cygwin utils over their
>native win counterparts?
Cygwin is slower. Cygwin is known to be slower. And, if you give it
a few minutes of thought it is obvious why Cygwin has to be slower.
I as
On Tue, 21 Oct 2003, Linda W. wrote:
> Has anyone done any testing on performance of cygwin utils over their
> native win counterparts? The one that bothers me the most is the
> performance of cygwin "Find" and the windows 'find'. If I'm just
> looking for filenames (find /c/ -name \*.wav) vs. l
"Linda W." wrote:
> Has anyone done any testing on performance of cygwin utils over their
> native win
> counterparts? The one that bothers me the most is the performance of
> cygwin "Find"
> and the windows 'find'. If I'm just looking for filenames (find /c/
> -name \*.wav) vs.
> looking for *.
Has anyone done any testing on performance of cygwin utils over their
native win
counterparts? The one that bothers me the most is the performance of
cygwin "Find"
and the windows 'find'. If I'm just looking for filenames (find /c/
-name \*.wav) vs.
looking for *.wav in windows find GUI, the p
[EMAIL PROTECTED] wrote:
Hi,
Im seeing a severe perfomance hit from cygwin. Heres the result of
$time make_depend with a cygwin-compiled makedepend:
2.65user 27.90system 9:22.59elapsed 5%CPU (0avgtext+0avgdata 49
Hi,
Im seeing a severe perfomance hit from cygwin. Heres the result of
$time make_depend with a cygwin-compiled makedepend:
2.65user 27.90system 9:22.59elapsed 5%CPU (0avgtext+0avgdata 49856maxresident)k
0inputs+0
Hi all,
this is my current patch for get running the lmbench-20 patch1 source from
http://www.bitmover.com
Content
* initial patches from me.
* Tim Prince lib_timing.c patch.
* patch for disabling rpc checking without adding a new file.
* bug fix of lat_select check (based on a hint of Chr
Hi all,
the last days I have run the lmbench benchmark suite with cygwin and Suse Linux 7.1 on
a Toshiba Satellite Pro 4300
Serie with PIII 700 MHz, 320 MB RAM.
I was very surprised about the differences in some tests. While some tests produces
expected results for example in
the "processor re
>
> On Sat, Jan 26, 2002 at 08:14:47PM +0100, Ralf Habacker wrote:
> >while makeing some tests I recognized, that sometime select() and
> >close() crashes, if the number of used file descriptors is > 60.
>
> grep /usr/include/sys/types.h for "FD_SETSIZE". You'll note that it is,
> by default, 6
On Sat, Jan 26, 2002 at 08:14:47PM +0100, Ralf Habacker wrote:
>while makeing some tests I recognized, that sometime select() and
>close() crashes, if the number of used file descriptors is > 60.
grep /usr/include/sys/types.h for "FD_SETSIZE". You'll note that it is,
by default, 64. Set it to s
Hi all,
while makeing some tests I recognized, that sometime select() and close() crashes, if
the number of used file
descriptors is > 60.
With a value >93 select() crashes.
With a value between 61 and 81 a close() call crashes instead of select(), but it
seems that this is caused by the
previ
> > -Original Message-
> > From: Tim Prince [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, December 02, 2001 10:58 PM
> > To: Ralf Habacker
> > Cc: Cygwin
> > Subject: Re: Old Thread: Cygwin Performance
> >
> >
The QueryPerformance() calls a
t; <[EMAIL PROTECTED]>
To: "Cygwin" <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 7:13 AM
Subject: RE: Old Thread: Cygwin Performance
> > -Original Message-
> > From: Tim Prince [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, December 02, 2001 10:58 P
Thanks, this got it started. I may be able to try a few runs by the end of
the day.
- Original Message -
From: "Ralf Habacker" <[EMAIL PROTECTED]>
To: "Cygwin" <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 7:13 AM
Subject: RE: Old Thread: Cygwin
> -Original Message-
> From: Tim Prince [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 02, 2001 10:58 PM
> To: Ralf Habacker
> Cc: Cygwin
> Subject: Re: Old Thread: Cygwin Performance
>
>
> Your patch adds lib_cygwin.c to the list of required source files,
gt;
Sent: Sunday, December 02, 2001 10:29 AM
Subject: RE: Old Thread: Cygwin Performance
> > I'd suggest you offer your patch to the lmbench maintainers. At one
time,
> > they were talking about supporting something for Windows. If they don't
> > adopt it, I suppo
t;[EMAIL PROTECTED]>
To: "Tim Prince" <[EMAIL PROTECTED]>
Cc: "Cygwin" <[EMAIL PROTECTED]>
Sent: Sunday, December 02, 2001 10:29 AM
Subject: RE: Old Thread: Cygwin Performance
> > I'd suggest you offer your patch to the lmbench maintainers. At one
time,
&
alf
> - Original Message -
> From: "Ralf Habacker" <[EMAIL PROTECTED]>
> To: "Tim Prince" <[EMAIL PROTECTED]>
> Cc: "Cygwin" <[EMAIL PROTECTED]>
> Sent: Saturday, December 01, 2001 11:44 AM
> Subject: RE: Old Thread: Cygwi
83 matches
Mail list logo
