Mail Archives: cygwin/2001/11/19/02:59:02
------=_NextPart_000_0039_01C170D8.F38AEEE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
> -----Ursprüngliche Nachricht-----
> Von: cygwin-owner AT sources DOT redhat DOT com
> [mailto:cygwin-owner AT sources DOT redhat DOT com]Im Auftrag von Ralf Habacker
> Gesendet am: Mittwoch, 14. November 2001 16:22
> An: cygwin AT cygwin DOT com
> Betreff: AW: cygwin vfork
>
> > -----Ursprüngliche Nachricht-----
> > Von: cygwin-owner AT sources DOT redhat DOT com
> > [mailto:cygwin-owner AT sources DOT redhat DOT com]Im Auftrag von Christopher
> > Faylor
> > Gesendet am: Dienstag, 13. November 2001 19:15
> > An: cygwin AT cygwin DOT 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
------=_NextPart_000_0039_01C170D8.F38AEEE0
Content-Type: application/x-gzip;
name="fileiotest-0.0.1.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="fileiotest-0.0.1.tar.gz"
H4sIAMm6+DsAA+1YbU/bSBDma5D4D3MpCBucxE54OZEGUXHpHbq+SEC/HCDk2OtkhbOOdh1Ser3/
fjO7dnAghCIVqt55JMh6d56ZnZedHTviMeNJPVh6RnI9193d3V1yXRxtuebX9eiXaGu71Vxyd1u7
O17L9bZ2ib/Z9JbAfc5N5TRWqS8BHuX7k3Hx/Lt5cXrFRRCPQwavVRpiIgz2V5Zv55iU4u6cSiUX
fT2J0yGLuGDQG0eKf2Gws73d2qGFYIBe3fBHI+EPWZtmrhMeQjBgwdWlSJKRZTiUvbL898ryP3c4
IkzLZMTELFfl7dG7LmxwgQIrXEAHIs2knOqkV7VplhYisH7hwgZCVEa42zSyqoEv1lMgdiDhsL6m
1qEG2sLOWnguqo5y9JOWU2GfeWp5eoybazSmgtaUZVcdyExzLi/ffvpweHr08cPlpeaOgjhRzMIN
tOfbNZE8ZblhDgoFcl1moZ5Gb55lHr1o3zM7Be4EyVikbXhpN1S0XlSog93Iw242gvr09No0G/bB
tWnJwDY3NV+USLB4x20Dh9eQGcI3N7ONRsY9KMIhGUlEQ9vxHONQvYtHXSyZH343D99zsvwxTv6O
Ptb+eaKLV5bJMUOfC4sGvuwHDhgfb+DDddG9G+rWkb5Wgubo2pDP5zZ6BUdaioxOpQwG0iKRZ+6F
s95Yt22yEr5+hfkc5+cZi03GZQeTGDc97Q0WKwazSxlWFyatm8yB/Q607KkvO36acKOleWHfYe10
YEuzknEFztY9zn3wbDB+VxOeBgOwtL/OvAsMh95XJfBxh+tifQ/IwKpIKHmkn/JEmKyutsGncPYw
clftIijJQTrTdM5pBAA8DJIzIMqGWZA3DzSZAeljmqPmgCiJjBNsbbuOei9G5rnVo7IwtysVRGa5
XSlU4vOU/ky01lrheaqjsfZrWCjQyhxlByVsZILNqTNbnCbHIrFQpPuyp6dmevTQyIcOnz4g5EKS
cOY1f9UFqKLzI9tCvupUU4bXsp+uhXX8X3V4tnPDPi/FHs6xQpIVbuFcld2uFCNeSK47F/JigJwB
6DIzNcZ4fh5qMoMyF8BCGHYd/jhO9yCPGY9j1vdjIH/BMME+xUrkxK4WI/1AuBdCczdzOvAm1lOd
WMangZcsHUuBMc+KJQJ/dGf3bfTev2Lk6ufUMdP/m76/2P83va2dvP/fbrlbyO/tNlsv3P8P/J4f
XDH5EN9/tP8/PXrf7TR6XDRSjjdjLYIqVr+uokshdnD4ScFYMUnDEwXqRlVXlg8/fvpw2sEYriyf
HP3VpZFLD8fdd903J92OW3frHh2Dw7fv3vx+0oHaxxa8qvVpyo/jPV3+eHIZ3PTz4VDR4u18zlMP
8DCtWoeHNuB/Lc6GWgKrB7D6GgqYoVoMGYqkhnIn2MrNwHXd2aOScLBqkTdsqDcK+xMkhOyl2/5A
DslFG1SN50OG6qkIUpI8WckTEaRkMoVgK6bj9W2qCrhb4FwNco6GeRLlPIlPtWHVotz7ZocVrShA
H7NjEesdS56yIWOL5wKYs/OEYCxGYULHzBd7xZWk+MA+M/NSM8Jy5/eZTn1cNCroEtyoY0Ws97/Q
AtXGWvDlOiqs11at7KDbOWd+8CC/TuC4++a3993sKqz86CpX0kNk4vS8Oh65/90db/r9b7vZ0ve/
t/XS3//+p/f/7bGGY4aVA7vj7PbuPEB0pk8HXEHM0zTOXgGZAiw/PlwzeQM9X/EgvoGYXbMYVIJ9
ha9GLEjx2jKFBHgC+J4yAHMj18EIZYBNCBd9GOJGxpLREBHZtZ0DUXWY0DfHG+zIhyOfPkdCimDB
WMhC0I0MwtJJQvtR+BKtFa8s85CJlAd5s49vccoBEjUZcHxnwj5H5crkWBhBMe9JH43yRahZxypX
N1TXgUzvcRpjjv04gj+ynMon6vnEQSQZEyythwzMt5Wf5X2hpJJKKqmkkkoqqaSSSiqppJJK+vno
XwX62mwAKAAA
------=_NextPart_000_0039_01C170D8.F38AEEE0
Content-Type: text/plain; charset=us-ascii
--
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/
------=_NextPart_000_0039_01C170D8.F38AEEE0--
- Raw text -