Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Christopher Faylor writes: Is Cygwin killing hard drives ? In my case, the hard drive has never seen cygwin, even the cygwin source code, so if it is, it would be action at a distance. Wow, that Cygwin software is even more poweful than I imagined :-P Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- 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/
RE: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
-Original Message- From: cygwin-owner On Behalf Of Christopher Faylor Sent: 27 June 2004 01:23 On Sat, Jun 26, 2004 at 10:45:51PM +0100, Mark Thornton wrote: Pierre A. Humblet wrote: On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? That crossed my mind. But there is no file lock in the macro, which is used by systems other than cygwin. How do they manage it? I also assume that single threaded programs don't need the lock. Is the lock to ensure that normal POSIX append semantics are obtained when two processes are writing to the same file? Normal win32 behaviour would tend to overwrite whatever had been written by the other process No. newlib is supposed to be OS agnostic. The locks are certainly for multi-threaded purposes. Anyone who is interested could always ask in the newlib mailing list. newlib sourceware org. cgf Those flockfile calls are part of Tom Pfaff's recent fixes to make stdio multithread-safe. Without them you can't even have multiple threads calling printf at the same time without their outputs corrupting each other. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sun, Jun 27, 2004 at 03:42:05PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 01:41:45PM -0400, Pierre A. Humblet wrote: Digging deeper, I see there is a function getc_unlocked. Using it instead of getc improves the speed by a factor 5. Now that I know about it, I will redefine getc to getc_unlocked when porting single threaded applications. That issue may be a factor in the legendary slowness of Cygwin. FWIW, I added some code to this particular locking function to avoid doing any locks if there is only one thread. I'm generating a snapshot now. It will be interesting to see if it improves things. I didn't do any benchmarking. I just verified that it worked the way I thought it should by looking at strace output. Here it is, using a slightly modified version of Joseph's program http://cygwin.com/ml/cygwin/2004-06/msg00877.html Your change makes getc work almost as fast a getc_unlocked. This is on Win98. Yesterday's results were on WinME, where the differences were larger. That hard drive died this morning :( CYGWIN_98-4.10 Worldnet 1.5.10(0.116/4/2) 2004-05-25 22:07 i586 unknown unknown Cygwin W:~: time a.exe daqsystem.pdf 1 (read) real0m0.282s W:~: time a.exe daqsystem.pdf 2 (getc_unlocked) real0m1.295s W:~: time a.exe daqsystem.pdf 3 (getc) real0m3.188s CYGWIN_98-4.10 Worldnet 1.5.11s(0.116/4/2) 20040627 15:47:35 i586 unknown unknown Cygwin W:~: time a.exe daqsystem.pdf 1 (read) real0m0.275s W:~: time a.exe daqsystem.pdf 2 (getc_unlocked) real0m1.294s W:~: time a.exe daqsystem.pdf 3 (getc) real0m1.343s Pierre -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sun, Jun 27, 2004 at 05:29:50PM -0400, Pierre A. Humblet wrote: On Sun, Jun 27, 2004 at 03:42:05PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 01:41:45PM -0400, Pierre A. Humblet wrote: Digging deeper, I see there is a function getc_unlocked. Using it instead of getc improves the speed by a factor 5. Now that I know about it, I will redefine getc to getc_unlocked when porting single threaded applications. That issue may be a factor in the legendary slowness of Cygwin. FWIW, I added some code to this particular locking function to avoid doing any locks if there is only one thread. I'm generating a snapshot now. It will be interesting to see if it improves things. I didn't do any benchmarking. I just verified that it worked the way I thought it should by looking at strace output. Here it is, using a slightly modified version of Joseph's program http://cygwin.com/ml/cygwin/2004-06/msg00877.html Your change makes getc work almost as fast a getc_unlocked. This is on Win98. Yesterday's results were on WinME, where the differences were larger. That hard drive died this morning :( Sorry to hear that. I've been going through hard disk problems myself. Thanks for verifying that the change worked. cgf -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sun, 27 Jun 2004, Christopher Faylor wrote: On Sun, Jun 27, 2004 at 05:29:50PM -0400, Pierre A. Humblet wrote: Your change makes getc work almost as fast a getc_unlocked. This is on Win98. Yesterday's results were on WinME, where the differences were larger. That hard drive died this morning :( Sorry to hear that. I've been going through hard disk problems myself. Is Cygwin killing hard drives ? -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sun, Jun 27, 2004 at 11:52:29PM -0300, Fr?d?ric L. W. Meunier wrote: On Sun, 27 Jun 2004, Christopher Faylor wrote: On Sun, Jun 27, 2004 at 05:29:50PM -0400, Pierre A. Humblet wrote: Your change makes getc work almost as fast a getc_unlocked. This is on Win98. Yesterday's results were on WinME, where the differences were larger. That hard drive died this morning :( Sorry to hear that. I've been going through hard disk problems myself. Is Cygwin killing hard drives ? In my case, the hard drive has never seen cygwin, even the cygwin source code, so if it is, it would be action at a distance. cgf -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Thank you to everyone for your help with my question. I hope the responses may also have been of some use to others besides me. I will download the new dll from http://www.cygwin.com/snapshots/ and see if it fixes my problems. Actually I upgraded from a 1.1.x version of Cygwin which is why I asked about the mounts. I guess that was not really relevant. I will try the settings for text mode that were suggested also. I think I had almost those same settings though and I was getting textmode when I specified absolute paths like /tmp/foo.txt but binmode for the same file if I called it foo.txt while in the /tmp/ directory. Apart from that I have not had any really serious issues (that I know of!) in upgrading, so I am very impressed with the stability of the package. Thanks again -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Thanks to those who responded to my post. I am not sure though if all of you read the entire sequence of the thread. In my first post, I did attach an excerpt from an strace dump of a sample program that seemed to show where the time is going. Here is the relevant information again in case it was missed the first time (showing longest operations in the strace dump): 171674 127276583 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 158323 5071628 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 144645 74466322 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 133088 48059 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 118305 4774629 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 115336 6690357 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 114418 79036229 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 113172 69211692 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 112608 6888268 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 108520 47854275 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 107589 6137061 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 106538 69397028 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 106369 1959755 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 12 67943460 [main] test1 613445 fhandler_base::set_flags: flags 0x11, supplied_bin 0x0 99220 64838744 [main] test1 613445 setmode_helper: improbable, but 2 != 3 96976 110763753 [main] test1 613445 setmode_helper: improbable, but 0 != 3 The program I am tracing simply opens a large file (about 7 MB) with fopen and then reads characters from it with getc, and does nothing else. It takes about 10-20 times longer than a program which opens the same file with open and reads it with read. In the strace of this faster program, the time is dominated by calls to readv. In my original post I also included the output of cygcheck on my system. Please advise if I should post this again. Also if it would help to see the lines in the strace dump in context, as opposed to sorted by duration of each operation, I could post that. Based on the instructions listed at the problems.html webpage on the Cygwin site, I thought this was sufficient information to begin a request for assistance. I do not really understand what you are advising me to do beyond this when you say I should debug cygwin. I sure would appreciate some guidance in how to do this. Possibly I should add that I am comparing the behavior of version 1.5.10 to a much older version that I was using before. So whatever is causing this odd behavior on my system may not be a feature that was new to version 1.5.10. I am thinking somehow that it might in fact have something to do with how mounts are handled differently in more recent versions. Previously I did not have to mount any directories, now though I am having trouble finding any set of mount commands that will allow me to open files in text mode by default, which was how the earlier version of cygwin I had worked. Nor does setting the CYGWIN environment variable to nobinmode seem to have any effect. Thanks again for any help -- 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/
RE: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Possibly I should add that I am comparing the behavior of version 1.5.10 to a much older version that I was using before. It wasn't by chance... oh... say... B20? ;-) So whatever is causing this odd behavior on my system may not be a feature that was new to version 1.5.10. I am thinking somehow that it might in fact have something to do with how mounts are handled differently in more recent versions. Previously I did not have to mount any directories, Yikes. I can't recall a time when you didn't have to mount directories, and I've been round these parts forever. That must be some *old* Cygwin! now though I am having trouble finding any set of mount commands that will allow me to open files in text mode by default, which was how the earlier version of cygwin I had worked. Nor does setting the CYGWIN environment variable to nobinmode seem to have any effect. Don't worry about the CYGWIN var anymore, it's all mounts these days. mount --help and umount --help is what you want. Set up your mount table like this: C:\unix\bin on /usr/bin type system (textmode) C:\unix\lib on /usr/lib type system (textmode) C:\unix on / type system (textmode) c: on /cygdrive/c type user (textmode,noumount) d: on /cygdrive/d type user (textmode,noumount) e: on /cygdrive/e type user (textmode,noumount) And you're all set. You have to umount before mounting if any of the directories are already mounted unfortunately (last I checked anyway). -- Gary R. Van Sickle -- 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/ -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 02:36:52AM -0400, Joseph wrote:
Thanks to those who responded to my post.
I am not sure though if all of you read the
entire sequence of the thread.
In my first post, I did attach an excerpt
from an strace dump of a sample program that
seemed to show where the time is going.
You initial accusation against set_flags was unfounded
and led nowhere. But you have a very good point.
Your fast program is doing reads in blocks of 1024.
Your slow program is using getc.
I observed that the slow program was 20 times slower
than the fast one, even though strace showed that getc
was properly calling read in blocks of 1024.
I then noticed that getc is not implemented as a macro
on Cygwin. It's a newlib function
74 int
75 _DEFUN(getc, (fp),
76 register FILE *fp)
77 {
78int result;
79_flockfile (fp);
80/* CHECK_INIT is called (eventually) by __srefill. */
81result = __sgetc (fp);
82_funlockfile (fp);
83return result;
(gdb)
84 }
_flockfile calls a bunch of pthread functions. That's where all
the time is spent, a large part of it verifying that pointers
are valid.
It's probably a relatively new feature of Cygwin. Others may know
more about the history and justification of implementation.
Pierre
--
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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 11:45:04AM -0400, Pierre A. Humblet wrote: On Sat, Jun 26, 2004 at 02:36:52AM -0400, Joseph wrote: Thanks to those who responded to my post. I am not sure though if all of you read the entire sequence of the thread. In my first post, I did attach an excerpt from an strace dump of a sample program that seemed to show where the time is going. You initial accusation against set_flags was unfounded and led nowhere. But you have a very good point. Your fast program is doing reads in blocks of 1024. Your slow program is using getc. I observed that the slow program was 20 times slower than the fast one, even though strace showed that getc was properly calling read in blocks of 1024. I then noticed that getc is not implemented as a macro on Cygwin. It's a newlib function As you seem to care about a 20x speed increase, you can regain the speed by editing stdio.h, letting getc be a macro on Cygwin. Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Pierre -- 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/
RE: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, 26 Jun 2004, GARY VANSICKLE wrote: [snip] You have to umount before mounting if any of the directories are already mounted unfortunately (last I checked anyway). Take a look a the -f option to mount. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? cgf -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? That crossed my mind. But there is no file lock in the macro, which is used by systems other than cygwin. How do they manage it? I also assume that single threaded programs don't need the lock. I would be perfectly happy to have a thread-unsafe getc/putc macro, and to use fgetc/fputc when I care about multithreading. Digging deeper, I see there is a function getc_unlocked. Using it instead of getc improves the speed by a factor 5. Now that I know about it, I will redefine getc to getc_unlocked when porting single threaded applications. That issue may be a factor in the legendary slowness of Cygwin. Pierre -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 01:41:45PM -0400, Pierre A. Humblet wrote: On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? That crossed my mind. But there is no file lock in the macro, which is used by systems other than cygwin. How do they manage it? They may not care of about this. That issue may be a factor in the legendary slowness of Cygwin. AFAICT, this lock was introduced in April so if it is part of the legend it has grown to prominence very quickly. cgf -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Pierre A. Humblet wrote: On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? That crossed my mind. But there is no file lock in the macro, which is used by systems other than cygwin. How do they manage it? I also assume that single threaded programs don't need the lock. Is the lock to ensure that normal POSIX append semantics are obtained when two processes are writing to the same file? Normal win32 behaviour would tend to overwrite whatever had been written by the other process unless the file is only opened once and then the handle duplicated (very messy). So if you want append mode to work correctly (i.e. Unix style), then you always have to use file locks around any file write operation that is expected to be atomic. The locks could be avoided for non append mode writes and where the file has been exclusively locked anyway. Single thread programs will need the lock just as much as multithread. You can only avoid it if you just a single process (with just one thread),. Mark Thornton -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Sat, Jun 26, 2004 at 10:45:51PM +0100, Mark Thornton wrote: Pierre A. Humblet wrote: On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote: On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote: Beware, I found this: 2000-05-19 DJ Delorie [EMAIL PROTECTED] * libc/include/stdio.h: no getc/putc macros for cygwin; causes compatibility issues with different dll versions so you may need to recompile when updating cygwin. Also wouldn't that work around the file locks that were ostensibly put there for a reason? That crossed my mind. But there is no file lock in the macro, which is used by systems other than cygwin. How do they manage it? I also assume that single threaded programs don't need the lock. Is the lock to ensure that normal POSIX append semantics are obtained when two processes are writing to the same file? Normal win32 behaviour would tend to overwrite whatever had been written by the other process No. newlib is supposed to be OS agnostic. The locks are certainly for multi-threaded purposes. Anyone who is interested could always ask in the newlib mailing list. newlib sourceware org. cgf -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Tue, 22 Jun 2004, sevenrider wrote: I am just asking again about this problem in the hopes that someone might have anything to suggest. It seems that fopen is 10 to 20 times slower than open on my I/O operations due to large delays in executing a system call set_flags. I will have to rewrite all my code and abandon most of the text utility programs like grep and sort unless I can figure out what is going on. Any help, just simple reference to what set_flags means in the strace dump, would be very much appreciated. If you have not made any progress on this, could you send me your strace output and a sample program if possible? I'd like to look at it as my time permits. If you prefer, personal email is fine. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Uh..., nevermind. That's what I get for reading the thread backward. Sorry for the noise. I'll take a look. On Wed, 23 Jun 2004, Brian Ford wrote: If you have not made any progress on this, could you send me your strace output and a sample program if possible? I'd like to look at it as my time permits. If you prefer, personal email is fine. Thanks. -- Brian Ford Senior Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained pilot... -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
I am just asking again about this problem in the hopes that someone might have anything to suggest. It seems that fopen is 10 to 20 times slower than open on my I/O operations due to large delays in executing a system call set_flags. I will have to rewrite all my code and abandon most of the text utility programs like grep and sort unless I can figure out what is going on. Any help, just simple reference to what set_flags means in the strace dump, would be very much appreciated. -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
On Tue, Jun 22, 2004 at 11:14:17PM -0400, [EMAIL PROTECTED] wrote: I am just asking again about this problem in the hopes that someone might have anything to suggest. It seems that fopen is 10 to 20 times slower than open on my I/O operations due to large delays in executing a system call set_flags. I will have to rewrite all my code and abandon most of the text utility programs like grep and sort unless I can figure out what is going on. Seems like if you are going to go to the effort of rewriting everything you might first want to debug cygwin and find out where the time is going... -- Christopher Faylor spammer? - [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- 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/
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
At 11:42 PM 6/22/2004, you wrote On Tue, Jun 22, 2004 at 11:14:17PM -0400, [EMAIL PROTECTED] wrote: I am just asking again about this problem in the hopes that someone might have anything to suggest. It seems that fopen is 10 to 20 times slower than open on my I/O operations due to large delays in executing a system call set_flags. I will have to rewrite all my code and abandon most of the text utility programs like grep and sort unless I can figure out what is going on. Seems like if you are going to go to the effort of rewriting everything you might first want to debug cygwin and find out where the time is going... Dag-namit! CGF beat me to the punch. :-) I would only add that there are two set_flag routines. One in path.cc, the other in fhandler.h/fhandler.cc. They don't do allot. Just setting flags really (who would have guessed? ;-) ) and no one has fiddled with these in the 1.5.10 time-frame. It's hard to imagine that either of these routines are what's responsible for all the time you see lost. CGF is right (who would have guessed! ;-) ). Debugging the internals a little bit would be time well spent, especially given the alternative you describe. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
