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