Date: Tue, 4 Jan 2000 03:33:12 +0100 From: Sascha Schumann <sascha@schumann.cx> To: Sasha Pachev <sasha@mysql.com> Cc: Leif Neland <leif@neland.dk>, monty@tcx.se, Paul DuBois <paul@snake.net>, mysql@lists.mysql.com, freebsd-current@freebsd.org Subject: Re: 2 hours to compile mysql? Message-ID: <20000104033311.A28282@schumann.cx> In-Reply-To: <387159A8.C46C69E1@mysql.com>; from sasha@mysql.com on Mon, Jan 03, 2000 at 07:23:36PM -0700 References: <Pine.BSF.4.05.10001020005001.55763-100000@arnold.neland.dk> <387159A8.C46C69E1@mysql.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 03, 2000 at 07:23:36PM -0700, Sasha Pachev wrote:
> Leif Neland wrote:
> >
> > > The reason for this is that some gcc optimizations stages takes
> > > exponentially more memory when compiling big functions.
> > > bison produces one big function for the grammar parsing and its
> > > this that takes a long time to compile; To compile sql_yacc.cc quickly
> > > on Intel, you nead at least 160M of free ram. On a PentiumII 400mz with 256M
> > > ram, it takes 11 seconds to compile sql_yacc.o. Having to use swap
> > > can easily make things 1000 times slower
> > >
> >
> > Is amount of ram available (portably) to configure?
> > So configure could decide to use --low-memory by itself? Allowing
> > overrides, naturally.
> >
> > Leif
> >
>
> There is actually a method to portably guess how much RAM your have available
> from configure -- just write a small C program that will keep malloc()-ing until
> it gets an error, but I do not think it is worth the effort.
There is also no guarantee that the allocated memory will be
available for real use (keyword resource overcommitting).
--
Regards,
Sascha Schumann
Consultant
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000104033311.A28282>