* cygwin vfork @ 2001-11-01 14:47 Charles Wilson 2001-11-01 16:27 ` Christopher Faylor ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Charles Wilson @ 2001-11-01 14:47 UTC (permalink / raw) To: cygwin Seen on the XEmacs list: > In general the cygwin build is slower, I think this is for 3 main > reasons: > > 1) gcc optimization is not as good as MSVC > 2) The cygwin portability layer adds a lot of overhead especially > wrt file handling. > 3) The cygwin implementation of fork-and-exec doesn't jive well with > the VM size of xemacs. Supposedly a real vfork is in the works for > cygwin but I can't attest to its functionality. Does #3 make any sense? I thought we *had* a real vfork...perhaps it doesn't work well with large apps? Or is the author just blowing smoke? --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-01 14:47 cygwin vfork Charles Wilson @ 2001-11-01 16:27 ` Christopher Faylor 2001-11-11 8:26 ` Christopher Faylor 2001-11-01 20:08 ` Tim Prince ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Christopher Faylor @ 2001-11-01 16:27 UTC (permalink / raw) To: cygwin On Mon, Nov 12, 2001 at 01:45:01PM -0500, Charles Wilson wrote: >Seen on the XEmacs list: > >> In general the cygwin build is slower, I think this is for 3 main >> reasons: >> >> 1) gcc optimization is not as good as MSVC >> 2) The cygwin portability layer adds a lot of overhead especially >> wrt file handling. >> 3) The cygwin implementation of fork-and-exec doesn't jive well with >> the VM size of xemacs. Supposedly a real vfork is in the works for >> cygwin but I can't attest to its functionality. > >Does #3 make any sense? I thought we *had* a real vfork...perhaps it >doesn't work well with large apps? Or is the author just blowing smoke? We have had a sort-of-vfork that should be faster than fork since 1.3.3, I think. No idea what the VM goobledy-gook is referring to. Cygwin's vfork is just black magic that eventually results in running spawn(P_NOWAIT) rather than fork/exec. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-01 16:27 ` Christopher Faylor @ 2001-11-11 8:26 ` Christopher Faylor 0 siblings, 0 replies; 16+ messages in thread From: Christopher Faylor @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin On Mon, Nov 12, 2001 at 01:45:01PM -0500, Charles Wilson wrote: >Seen on the XEmacs list: > >> In general the cygwin build is slower, I think this is for 3 main >> reasons: >> >> 1) gcc optimization is not as good as MSVC >> 2) The cygwin portability layer adds a lot of overhead especially >> wrt file handling. >> 3) The cygwin implementation of fork-and-exec doesn't jive well with >> the VM size of xemacs. Supposedly a real vfork is in the works for >> cygwin but I can't attest to its functionality. > >Does #3 make any sense? I thought we *had* a real vfork...perhaps it >doesn't work well with large apps? Or is the author just blowing smoke? We have had a sort-of-vfork that should be faster than fork since 1.3.3, I think. No idea what the VM goobledy-gook is referring to. Cygwin's vfork is just black magic that eventually results in running spawn(P_NOWAIT) rather than fork/exec. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-01 14:47 cygwin vfork Charles Wilson 2001-11-01 16:27 ` Christopher Faylor @ 2001-11-01 20:08 ` Tim Prince 2001-11-11 8:26 ` Tim Prince 2001-11-01 20:56 ` AW: " Ralf Habacker 2001-11-11 8:26 ` Charles Wilson 3 siblings, 1 reply; 16+ messages in thread From: Tim Prince @ 2001-11-01 20:08 UTC (permalink / raw) To: Charles Wilson, cygwin ----- Original Message ----- From: "Charles Wilson" <cwilson@ece.gatech.edu> To: <cygwin@cygwin.com> Sent: Monday, November 12, 2001 10:45 AM Subject: cygwin vfork > Seen on the XEmacs list: > > > In general the cygwin build is slower, I think this is for 3 main > > reasons: > > > > 1) gcc optimization is not as good as MSVC > > 2) The cygwin portability layer adds a lot of overhead especially > > wrt file handling. > > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > the VM size of xemacs. Supposedly a real vfork is in the works for > > cygwin but I can't attest to its functionality. > > Does #3 make any sense? I thought we *had* a real vfork...perhaps it > doesn't work well with large apps? Or is the author just blowing smoke? > > --Chuck > #1 doesn't make a great deal of sense either. I suppose it's possible to set up ground rules under which MSVC would optimize better than gcc, but it's not my experience. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-01 20:08 ` Tim Prince @ 2001-11-11 8:26 ` Tim Prince 0 siblings, 0 replies; 16+ messages in thread From: Tim Prince @ 2001-11-11 8:26 UTC (permalink / raw) To: Charles Wilson, cygwin ----- Original Message ----- From: "Charles Wilson" <cwilson@ece.gatech.edu> To: <cygwin@cygwin.com> Sent: Monday, November 12, 2001 10:45 AM Subject: cygwin vfork > Seen on the XEmacs list: > > > In general the cygwin build is slower, I think this is for 3 main > > reasons: > > > > 1) gcc optimization is not as good as MSVC > > 2) The cygwin portability layer adds a lot of overhead especially > > wrt file handling. > > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > the VM size of xemacs. Supposedly a real vfork is in the works for > > cygwin but I can't attest to its functionality. > > Does #3 make any sense? I thought we *had* a real vfork...perhaps it > doesn't work well with large apps? Or is the author just blowing smoke? > > --Chuck > #1 doesn't make a great deal of sense either. I suppose it's possible to set up ground rules under which MSVC would optimize better than gcc, but it's not my experience. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* AW: cygwin vfork 2001-11-01 14:47 cygwin vfork Charles Wilson 2001-11-01 16:27 ` Christopher Faylor 2001-11-01 20:08 ` Tim Prince @ 2001-11-01 20:56 ` Ralf Habacker 2001-11-02 1:17 ` Charles Wilson ` (2 more replies) 2001-11-11 8:26 ` Charles Wilson 3 siblings, 3 replies; 16+ messages in thread From: Ralf Habacker @ 2001-11-01 20:56 UTC (permalink / raw) To: cygwin > > Seen on the XEmacs list: > > > In general the cygwin build is slower, I think this is for 3 main > > reasons: > > > > 1) gcc optimization is not as good as MSVC > > 2) The cygwin portability layer adds a lot of overhead especially > > wrt file handling. > > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > the VM size of xemacs. Supposedly a real vfork is in the works for > > cygwin but I can't attest to its functionality. > > Does #3 make any sense? I thought we *had* a real vfork...perhaps it > doesn't work well with large apps? > Can you explain this a little bit more ? I'm asking because in http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described some problems with kde2 on cygwin relating performance and I'm very interested in getting more informations how to fix these problems. In short, loading the full kde2 desktop needs about 4 minutes and the reaction time for starting apps are > 1 minute. This seems to be unusable. My assumption are that these problems depends on application loading (vfork is used on every app), file and socket io. A regular kde2 app uses about 20-40 dll's, so a faster vfork would decrease the loading time. :-) Regards Ralf > --Chuck > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AW: cygwin vfork 2001-11-01 20:56 ` AW: " Ralf Habacker @ 2001-11-02 1:17 ` Charles Wilson 2001-11-02 6:00 ` Christopher Faylor 2001-11-11 8:26 ` Charles Wilson 2001-11-02 6:05 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker 2 siblings, 2 replies; 16+ messages in thread From: Charles Wilson @ 2001-11-02 1:17 UTC (permalink / raw) To: Ralf Habacker; +Cc: cygwin Ralf Habacker wrote: >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with >> > the VM size of xemacs. Supposedly a real vfork is in the works for >> > cygwin but I can't attest to its functionality. > Can you explain this a little bit more ? I'm asking because in > http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described > some problems with kde2 on cygwin relating performance and I'm very interested > in getting more informations how to fix these problems. In short, loading the > full kde2 desktop needs about 4 minutes and the reaction time for starting apps > are > 1 minute. This seems to be unusable. > My assumption are that these problems depends on application loading (vfork is > used on every app), file and socket io. > A regular kde2 app uses about 20-40 dll's, so a faster vfork would decrease the > loading time. :-) Well, this is the clarification that I received: > The VM comment is referring to the large footprint of XEmacs which means > that doing a fork requires copying an awful lot of data (and hence takes a > long time), most OS's do copy-on-write for vfork so the overhead is never > incurred. And of course, cgf chimed in on this thread, but I can't find his message in my mail archive, and (as mentioned elsewhere) the cygwin ml archive is missing his message as well, so I can't quote it here for you. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AW: cygwin vfork 2001-11-02 1:17 ` Charles Wilson @ 2001-11-02 6:00 ` Christopher Faylor 2001-11-11 8:26 ` Christopher Faylor 2001-11-11 8:26 ` Charles Wilson 1 sibling, 1 reply; 16+ messages in thread From: Christopher Faylor @ 2001-11-02 6:00 UTC (permalink / raw) To: cygwin On Tue, Nov 13, 2001 at 10:43:03AM -0500, Charles Wilson wrote: >> The VM comment is referring to the large footprint of XEmacs which means >> that doing a fork requires copying an awful lot of data (and hence takes a >> long time), most OS's do copy-on-write for vfork so the overhead is never >> incurred. > >And of course, cgf chimed in on this thread, but I can't find his message >in my mail archive, and (as mentioned elsewhere) the cygwin ml archive is >missing his message as well, so I can't quote it here for you. With vfork, there is very little copying going on. Only cygwin's heap is copied. Of course, if you don't use vfork then cygwin's fork implementation *is* pretty slow. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AW: cygwin vfork 2001-11-02 6:00 ` Christopher Faylor @ 2001-11-11 8:26 ` Christopher Faylor 0 siblings, 0 replies; 16+ messages in thread From: Christopher Faylor @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin On Tue, Nov 13, 2001 at 10:43:03AM -0500, Charles Wilson wrote: >> The VM comment is referring to the large footprint of XEmacs which means >> that doing a fork requires copying an awful lot of data (and hence takes a >> long time), most OS's do copy-on-write for vfork so the overhead is never >> incurred. > >And of course, cgf chimed in on this thread, but I can't find his message >in my mail archive, and (as mentioned elsewhere) the cygwin ml archive is >missing his message as well, so I can't quote it here for you. With vfork, there is very little copying going on. Only cygwin's heap is copied. Of course, if you don't use vfork then cygwin's fork implementation *is* pretty slow. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: AW: cygwin vfork 2001-11-02 1:17 ` Charles Wilson 2001-11-02 6:00 ` Christopher Faylor @ 2001-11-11 8:26 ` Charles Wilson 1 sibling, 0 replies; 16+ messages in thread From: Charles Wilson @ 2001-11-11 8:26 UTC (permalink / raw) To: Ralf Habacker; +Cc: cygwin Ralf Habacker wrote: >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with >> > the VM size of xemacs. Supposedly a real vfork is in the works for >> > cygwin but I can't attest to its functionality. > Can you explain this a little bit more ? I'm asking because in > http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described > some problems with kde2 on cygwin relating performance and I'm very interested > in getting more informations how to fix these problems. In short, loading the > full kde2 desktop needs about 4 minutes and the reaction time for starting apps > are > 1 minute. This seems to be unusable. > My assumption are that these problems depends on application loading (vfork is > used on every app), file and socket io. > A regular kde2 app uses about 20-40 dll's, so a faster vfork would decrease the > loading time. :-) Well, this is the clarification that I received: > The VM comment is referring to the large footprint of XEmacs which means > that doing a fork requires copying an awful lot of data (and hence takes a > long time), most OS's do copy-on-write for vfork so the overhead is never > incurred. And of course, cgf chimed in on this thread, but I can't find his message in my mail archive, and (as mentioned elsewhere) the cygwin ml archive is missing his message as well, so I can't quote it here for you. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-01 20:56 ` AW: " Ralf Habacker 2001-11-02 1:17 ` Charles Wilson @ 2001-11-02 6:05 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker 2001-11-11 8:26 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker 2 siblings, 2 replies; 16+ messages in thread From: Christopher Faylor @ 2001-11-02 6:05 UTC (permalink / raw) To: cygwin On Tue, Nov 13, 2001 at 12:48:24PM +0100, Ralf Habacker wrote: >> >> Seen on the XEmacs list: >> >> > In general the cygwin build is slower, I think this is for 3 main >> > reasons: >> > >> > 1) gcc optimization is not as good as MSVC >> > 2) The cygwin portability layer adds a lot of overhead especially >> > wrt file handling. >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with >> > the VM size of xemacs. Supposedly a real vfork is in the works for >> > cygwin but I can't attest to its functionality. >> >> Does #3 make any sense? I thought we *had* a real vfork...perhaps it >> doesn't work well with large apps? >> >Can you explain this a little bit more ? I'm asking because in >http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described >some problems with kde2 on cygwin relating performance and I'm very interested >in getting more informations how to fix these problems. In short, loading the >full kde2 desktop needs about 4 minutes and the reaction time for starting apps >are > 1 minute. This seems to be unusable. >My assumption are that these problems depends on application loading (vfork is >used on every app), file and socket io. You can't make an assumption like this. It's possible that there is something in your app which is short-circuiting cygwin's vfork. There are some pathological cases in which it will give up and revert to fork. It's unlikely that gcc's optimization is so very bad that you'd see orders of magnitude slowdowns. So, something else is going on. You'd have to debug the application to figure out what that is. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* AW: cygwin vfork 2001-11-02 6:05 ` Christopher Faylor @ 2001-11-11 8:26 ` Ralf Habacker 2001-11-11 8:26 ` Ralf Habacker 2001-11-11 8:26 ` Christopher Faylor 1 sibling, 1 reply; 16+ messages in thread From: Ralf Habacker @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin > -----Ursprüngliche Nachricht----- > Von: cygwin-owner@sources.redhat.com > [mailto:cygwin-owner@sources.redhat.com]Im Auftrag von Christopher > Faylor > Gesendet am: Dienstag, 13. November 2001 19:15 > An: cygwin@cygwin.com > Betreff: Re: cygwin vfork > > On Tue, Nov 13, 2001 at 12:48:24PM +0100, Ralf Habacker wrote: > >> > >> Seen on the XEmacs list: > >> > >> > In general the cygwin build is slower, I think this is for 3 main > >> > reasons: > >> > > >> > 1) gcc optimization is not as good as MSVC > >> > 2) The cygwin portability layer adds a lot of overhead especially > >> > wrt file handling. > >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with > >> > the VM size of xemacs. Supposedly a real vfork is in the works for > >> > cygwin but I can't attest to its functionality. > >> > >> Does #3 make any sense? I thought we *had* a real vfork...perhaps it > >> doesn't work well with large apps? > >> > >Can you explain this a little bit more ? I'm asking because in > >http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I > have described > >some problems with kde2 on cygwin relating performance and I'm very > interested > >in getting more informations how to fix these problems. In short, loading the > >full kde2 desktop needs about 4 minutes and the reaction time for > starting apps > >are > 1 minute. This seems to be unusable. > >My assumption are that these problems depends on application loading > (vfork is > >used on every app), file and socket io. > > You can't make an assumption like this. It's possible that there is > something in your app which is short-circuiting cygwin's vfork. There > are some pathological cases in which it will give up and revert to fork. Hmmh, it may be that vfork in the closest context would not be a problem, but remember the problem in dll_list::alloc http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00295.html where I have to increase the number of retries on searching a free memory area. I recognized, that there are sometimes over 150 tries needed to find a free block and when an application uses 40 dll's, this produces some overhead. Additional the performance of the windows run time loader seems to not be the best, especially when using c++ dll's with many symbols. There may be some more aspects I currently can't identify, and you're right, this has to be debugged. A few weeks ago I have build a debug release of the cygwin dll with printing some debug information in the dll loading stuff and recognized, that there are noticable delays on application loading. Second file and socket communication seems to be parts, which has to be observed. I have build a file io test app using fopen/fread/fwrite, which compares file io with cygwin and mscrt and this reports in some cases that file io with cygwin needs about than 10 times as much as with msvcrt to read/write files. In the next time I'm analysing this a little bit more. Regards Ralf > It's unlikely that gcc's optimization is so very bad that you'd see orders > of magnitude slowdowns. So, something else is going on. You'd have to > debug the application to figure out what that is. > > cgf > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* AW: cygwin vfork 2001-11-11 8:26 ` AW: " Ralf Habacker @ 2001-11-11 8:26 ` Ralf Habacker 0 siblings, 0 replies; 16+ messages in thread From: Ralf Habacker @ 2001-11-11 8:26 UTC (permalink / raw) To: Cygwin [-- Attachment #1: Type: text/plain, Size: 5310 bytes --] > -----Ursprüngliche Nachricht----- > Von: cygwin-owner@sources.redhat.com > [mailto:cygwin-owner@sources.redhat.com]Im Auftrag von Ralf Habacker > Gesendet am: Mittwoch, 14. November 2001 16:22 > An: cygwin@cygwin.com > Betreff: AW: cygwin vfork > > > -----Ursprüngliche Nachricht----- > > Von: cygwin-owner@sources.redhat.com > > [mailto:cygwin-owner@sources.redhat.com]Im Auftrag von Christopher > > Faylor > > Gesendet am: Dienstag, 13. November 2001 19:15 > > An: cygwin@cygwin.com > > Betreff: Re: cygwin vfork > > > > On Tue, Nov 13, 2001 at 12:48:24PM +0100, Ralf Habacker wrote: > > >> > > >> Seen on the XEmacs list: > > >> > > >> > In general the cygwin build is slower, I think this is for 3 main > > >> > reasons: > > >> > > > >> > 1) gcc optimization is not as good as MSVC > > >> > 2) The cygwin portability layer adds a lot of overhead especially > > >> > wrt file handling. > > >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > >> > the VM size of xemacs. Supposedly a real vfork is in the works for > > >> > cygwin but I can't attest to its functionality. > > >> > > >> Does #3 make any sense? I thought we *had* a real vfork...perhaps it > > >> doesn't work well with large apps? > > >> > > >Can you explain this a little bit more ? I'm asking because in > > >http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I > > have described > > >some problems with kde2 on cygwin relating performance and I'm very > > interested > > >in getting more informations how to fix these problems. In short, > loading the > > >full kde2 desktop needs about 4 minutes and the reaction time for > > starting apps > > >are > 1 minute. This seems to be unusable. > > >My assumption are that these problems depends on application loading > > (vfork is > > >used on every app), file and socket io. > > > > You can't make an assumption like this. It's possible that there is > > something in your app which is short-circuiting cygwin's vfork. There > > are some pathological cases in which it will give up and revert to fork. > > Hmmh, it may be that vfork in the closest context would not be a problem, but > remember the problem in dll_list::alloc > http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00295.html where > I have to > increase the number of retries on searching a free memory area. > I recognized, that there are sometimes over 150 tries needed to find a free > block and when an application uses 40 dll's, this produces some overhead. > Additional the performance of the windows run time loader seems to not be the > best, especially when using c++ dll's with many symbols. > There may be some more aspects I currently can't identify, and you're right, > this has to be debugged. > > A few weeks ago I have build a debug release of the cygwin dll with printing > some debug information in the dll loading stuff and recognized, that there are > noticable delays on application loading. > > Second file and socket communication seems to be parts, which has to be > observed. I have build a file io test app using fopen/fread/fwrite, which > compares file io with cygwin and mscrt and this reports in some cases > that file > io with cygwin needs about than 10 times as much as with msvcrt to read/write > files. In the next time I'm analysing this a little bit more. > Here are some results of the file io test program, which is appended. Note the differences in the read case $ make check fileio_cyg no operation check count=100 0:00.08s real, 0.04s user, 0.05s sys fileio_ms.exe no operation check count=100 0:00.08s real, 0.03s user, 0.05s sys fileio_cyg file open check count=100 0:00.16s real, 0.07s user, 0.10s sys fileio_ms.exe file open check count=100 0:00.11s real, 0.05s user, 0.03s sys fileio_cyg file write check count=100 size= 65536 0:01.72s real, 0.10s user, 0.51s sys fileio_ms.exe file write check count=100 size= 65536 0:01.29s real, 0.04s user, 0.04s sys fileio_cyg file read check count=100 size= 65536 0:01.06s real, 0.09s user, 0.12s sys fileio_ms.exe file read check count=100 size= 65536 0:00.12s real, 0.02s user, 0.06s sys ^^^^^^^^^^ fileio_cyg file write check count=100 size= 131072 0:11.98s real, 0.09s user, 0.73s sys fileio_ms.exe file write check count=100 size= 131072 0:08.13s real, 0.03s user, 0.03s sys fileio_cyg file read check count=100 size= 131072 0:02.33s real, 0.14s user, 0.12s sys fileio_ms.exe file read check count=100 size= 131072 0:00.14s real, 0.03s user, 0.04s sys ^^^^^^^^ fileio_cyg file write check count= 10 size= 1048576 0:08.70s real, 0.06s user, 0.52s sys fileio_ms.exe file write check count= 10 size= 1048576 0:04.53s real, 0.05s user, 0.03s sys It seems that the msvc runtime does a more efficient read caching as cygwin. Does anyone have some suggestions about the possible reason why ? Regards Ralf [-- Attachment #2: fileiotest-0.0.1.tar.gz --] [-- Type: application/x-gzip, Size: 1491 bytes --] [-- Attachment #3: Type: text/plain, Size: 214 bytes --] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: cygwin vfork 2001-11-02 6:05 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker @ 2001-11-11 8:26 ` Christopher Faylor 1 sibling, 0 replies; 16+ messages in thread From: Christopher Faylor @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin On Tue, Nov 13, 2001 at 12:48:24PM +0100, Ralf Habacker wrote: >> >> Seen on the XEmacs list: >> >> > In general the cygwin build is slower, I think this is for 3 main >> > reasons: >> > >> > 1) gcc optimization is not as good as MSVC >> > 2) The cygwin portability layer adds a lot of overhead especially >> > wrt file handling. >> > 3) The cygwin implementation of fork-and-exec doesn't jive well with >> > the VM size of xemacs. Supposedly a real vfork is in the works for >> > cygwin but I can't attest to its functionality. >> >> Does #3 make any sense? I thought we *had* a real vfork...perhaps it >> doesn't work well with large apps? >> >Can you explain this a little bit more ? I'm asking because in >http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described >some problems with kde2 on cygwin relating performance and I'm very interested >in getting more informations how to fix these problems. In short, loading the >full kde2 desktop needs about 4 minutes and the reaction time for starting apps >are > 1 minute. This seems to be unusable. >My assumption are that these problems depends on application loading (vfork is >used on every app), file and socket io. You can't make an assumption like this. It's possible that there is something in your app which is short-circuiting cygwin's vfork. There are some pathological cases in which it will give up and revert to fork. It's unlikely that gcc's optimization is so very bad that you'd see orders of magnitude slowdowns. So, something else is going on. You'd have to debug the application to figure out what that is. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* AW: cygwin vfork 2001-11-01 20:56 ` AW: " Ralf Habacker 2001-11-02 1:17 ` Charles Wilson 2001-11-02 6:05 ` Christopher Faylor @ 2001-11-11 8:26 ` Ralf Habacker 2 siblings, 0 replies; 16+ messages in thread From: Ralf Habacker @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin > > Seen on the XEmacs list: > > > In general the cygwin build is slower, I think this is for 3 main > > reasons: > > > > 1) gcc optimization is not as good as MSVC > > 2) The cygwin portability layer adds a lot of overhead especially > > wrt file handling. > > 3) The cygwin implementation of fork-and-exec doesn't jive well with > > the VM size of xemacs. Supposedly a real vfork is in the works for > > cygwin but I can't attest to its functionality. > > Does #3 make any sense? I thought we *had* a real vfork...perhaps it > doesn't work well with large apps? > Can you explain this a little bit more ? I'm asking because in http://sources.redhat.com/ml/cygwin-xfree/2001-q4/msg00276.html I have described some problems with kde2 on cygwin relating performance and I'm very interested in getting more informations how to fix these problems. In short, loading the full kde2 desktop needs about 4 minutes and the reaction time for starting apps are > 1 minute. This seems to be unusable. My assumption are that these problems depends on application loading (vfork is used on every app), file and socket io. A regular kde2 app uses about 20-40 dll's, so a faster vfork would decrease the loading time. :-) Regards Ralf > --Chuck > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* cygwin vfork 2001-11-01 14:47 cygwin vfork Charles Wilson ` (2 preceding siblings ...) 2001-11-01 20:56 ` AW: " Ralf Habacker @ 2001-11-11 8:26 ` Charles Wilson 3 siblings, 0 replies; 16+ messages in thread From: Charles Wilson @ 2001-11-11 8:26 UTC (permalink / raw) To: cygwin Seen on the XEmacs list: > In general the cygwin build is slower, I think this is for 3 main > reasons: > > 1) gcc optimization is not as good as MSVC > 2) The cygwin portability layer adds a lot of overhead especially > wrt file handling. > 3) The cygwin implementation of fork-and-exec doesn't jive well with > the VM size of xemacs. Supposedly a real vfork is in the works for > cygwin but I can't attest to its functionality. Does #3 make any sense? I thought we *had* a real vfork...perhaps it doesn't work well with large apps? Or is the author just blowing smoke? --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-11-19 7:58 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-11-01 14:47 cygwin vfork Charles Wilson 2001-11-01 16:27 ` Christopher Faylor 2001-11-11 8:26 ` Christopher Faylor 2001-11-01 20:08 ` Tim Prince 2001-11-11 8:26 ` Tim Prince 2001-11-01 20:56 ` AW: " Ralf Habacker 2001-11-02 1:17 ` Charles Wilson 2001-11-02 6:00 ` Christopher Faylor 2001-11-11 8:26 ` Christopher Faylor 2001-11-11 8:26 ` Charles Wilson 2001-11-02 6:05 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker 2001-11-11 8:26 ` Ralf Habacker 2001-11-11 8:26 ` Christopher Faylor 2001-11-11 8:26 ` AW: " Ralf Habacker 2001-11-11 8:26 ` Charles Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).