From xemacs-m  Fri Jun  6 23:32:44 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id XAA21396
	for <xemacs-beta@xemacs.org>; Fri, 6 Jun 1997 23:32:43 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA16490 for <xemacs-beta@xemacs.org>; Fri, 6 Jun 1997 21:51:14 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id VAA23042; Fri, 6 Jun 1997 21:31:16 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA06832; Fri, 6 Jun 1997 21:31:13 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id VAA12331; Fri, 6 Jun 1997 21:31:11 -0700
Date: Fri, 6 Jun 1997 21:31:11 -0700
Message-Id: <199706070431.VAA12331@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: xemacs-beta@xemacs.org
Subject: Re: Warsaw: SUCCESS on sparc-sun-solaris2.5
In-Reply-To: <m24tbbi9or.fsf@altair.xemacs.org>
References: <kigbu5jgwdz.fsf@jagor.srce.hr>
	<m24tbbi9or.fsf@altair.xemacs.org>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta3)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "sb" == Steven L Baur <steve@xemacs.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
>> WARNING: ---------------------------------------------------------
>> WARNING: Compiling in support for runtime error checking.
>> WARNING: XEmacs will run noticeably more slowly as a result.
>> WARNING: Error checking is on by default for XEmacs beta releases.
>> WARNING: ---------------------------------------------------------

>> A question: What exactly do we get with this error checking?  I can't
>> really afford the substantial slowdown in everyday work, unless it
>> offers real advantages otherwise.

sb> If you don't have problems that you cannot trace down (and fix) yourself
sb> you probably do not need it.  The solution I use is to keep two builds
sb> around (with --srcdir), one compiled balls-to-the-walls-mega-optimized
sb> for day-to-day use (that's the one I'm typing in now) and a second copy
sb> compiled with all error checking, debug, etc. turned on for debugging.

I do exactly the same thing.

sb> An intermediate solution if you have space for only one build is to
sb> turn off the error checking and debug options, but leave in `-g'.

Keep the --debug option; that should not slow XEmacs down ... err, much.

sb> There is little pain with `-g' if you are using gcc because you can
sb> still compile optimized.  It's not quite as good, but is passable and
sb> the C backtraces come with line numbers so there's a chance that
sb> enough information to figure out what went wrong will be left in a
sb> core dump.

The question is - do you want an XEmacs that is really slow because
it's constantly looking for an appropriate place to core dump?  The
answer should be yes, so that the unwashed masses don't suffer as we
do.  

I have a special reason for building un-optimized - these days I build 
XEmacs many times a day, and unoptimized means faster configure+build.

(says Martin, typing into his optimized XEmacs 20.3-b4).

