This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]