AW: cygwin vfork

Ralf Habacker Ralf.Habacker@freenet.de
Sun Nov 11 08:26:00 GMT 2001


> -----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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileiotest-0.0.1.tar.gz
Type: application/x-gzip
Size: 1491 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20011111/fd069d74/attachment.bin>
-------------- next part --------------
--
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/


More information about the Cygwin mailing list