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] |
> -----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
Attachment:
fileiotest-0.0.1.tar.gz
Description: GNU Zip compressed data
-- 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] |