Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Ralf Habacker" To: "Cygwin" Subject: AW: cygwin vfork Date: Mon, 19 Nov 2001 09:02:44 +0100 Message-ID: <003801c170d0$91c686e0$651c440a@BRAMSCHE> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C170D8.F38AEEE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <002201c16d20$10f53150$651c440a@BRAMSCHE> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal ------=_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--