attempt to send plain text email.

Ranjit Mathew rmathew4lists@hotmail.com
Fri Feb 28 06:52:00 GMT 2003


> > > building GCC on MingW is not an easy task. Contrast this to the
> > > speed (~3 hours) at which I can build the cross-compiler and native
> > > compiler on Linux and it is no contest.
> >
> >I wonder why that is.
>> I'm not incriminating Windows. The Visual Studio command-line equivalents
> of make, gcc, etc. scream on Win32. It probably has to do with MSYS
> (the MingW bash equivalent) having to translate POSIX pathnames before
> feeding them to Win32 processes it spawns or something like that. Ranjit
> or some MSYS guru could explain this better than me.

Though I'm certainly not anywhere near being an MSYS or Cygwin guru, 
here's some fodder for thought:
1. Since MinGW does not have scandir/alphasort (yet), it does not
 benefit from this build time optimisation:
 http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01556.html
 This should be fairly easy to correct - opendir, readdir, etc.
 are already present in libmingwex.
2. The libgcj build process results in an awful lot of short-lived
 processes being created and destroyed. Cygwin and MSYS (which is
 based on an earlier release of cygwin1.dll), use a...errr...
 "complicated" implementation of fork( ) that certainly doesn't
 contribute to making things fast:
 http://cygwin.com/faq/faq_4.html#SEC77
3. From my personal experience, Linux filesystems like ext2/ext3 and
 ReiserFS are screaming fast compared to the FAT32/NTFS filesystems
 (of course this could also be due to the implementation of the
 filesystem bits in the respective kernels).
4. It could just be that the focus of Cygwin hackers is to first make
 things work correctly and then work on making them as fast as
 possible - in other words, hopefully things would get better in
 the future.
Ranjit.


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /