From owner-freebsd-current Mon Jan 3 18:33:55 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.iserlohn.netsurf.de (mail.iserlohn.netsurf.de [194.195.194.253]) by hub.freebsd.org (Postfix) with ESMTP id 87ACD1504F for ; Mon, 3 Jan 2000 18:33:43 -0800 (PST) (envelope-from sascha@schumann.cx) Received: from schumann.cx (hennen32s.iserlohn.netsurf.de [194.195.194.226]) by mail.iserlohn.netsurf.de (8.9.1/8.9.1) with SMTP id DAA23879 for ; Tue, 4 Jan 2000 03:33:37 +0100 Received: (qmail 83929 invoked from network); 4 Jan 2000 02:33:12 -0000 Received: from flaubert.foo.bar (192.168.0.99) by guerilla.foo.bar with SMTP; 4 Jan 2000 02:33:12 -0000 Received: (qmail 28297 invoked by uid 500); 4 Jan 2000 02:33:12 -0000 Date: Tue, 4 Jan 2000 03:33:12 +0100 From: Sascha Schumann To: Sasha Pachev Cc: Leif Neland , monty@tcx.se, Paul DuBois , mysql@lists.mysql.com, freebsd-current@freebsd.org Subject: Re: 2 hours to compile mysql? Message-ID: <20000104033311.A28282@schumann.cx> References: <387159A8.C46C69E1@mysql.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <387159A8.C46C69E1@mysql.com>; from sasha@mysql.com on Mon, Jan 03, 2000 at 07:23:36PM -0700 X-Notice: Copyright (c) 2000 Sascha Schumann. All rights reserved. X-Operating-System: Linux 2.2.13 #10 Mon Dec 27 20:35:15 CET 1999 alpha Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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