-;;;; $Header$
-
-;;; TO DO: Might it be possible to increase the efficiency of CMU CL's garbage
-;;; collection on my large (256Mb) machine by doing larger incremental GC steps
-;;; than the default 2 Mb of CMU CL 2.4.9? A quick test 19990729, setting this
-;;; to 5E6 showed no significant improvement, but it's possible that more
-;;; cleverness might help..
-;#+cmu (setf ext:*bytes-consed-between-gcs* (* 5 (expt 10 6)))
+;;; GC tuning has little effect on the x86 due to the generational
+;;; collector. For the older stop & copy collector, it assuredly
+;;; does. GC time is proportional to the amount of non-garbage
+;;; needing collection and copying; when the application involved is
+;;; the SBCL compiler, it doesn't take any longer to collect 20 Mb than
+;;; to collect 2 Mb. -dan, 20000819
+;;;
+;;; Actually, tweaking *BYTES-CONSED-BETWEEN-GCS* to 20Mb instead of
+;;; the default 2 seemed to make SBCL rebuild O(25%) faster on my 256
+;;; Mb K6/3, so I think it does have some effect on X86/GENCGC. I
+;;; haven't looked into why this would be, though. Also, I'm afraid
+;;; that using 20Mb here might be unfriendly to people using more-reasonable
+;;; machines (like old laptops with 48Mb of memory..) so I've
+;;; suppressed this tweak except for Alpha. -- WHN 2001-05-11
+#+(and sbcl alpha) ; SBCL/Alpha uses stop-and-copy, and Alphas have lotso RAM.
+(progn
+ (sb-ext:gc-off)
+ (setf (bytes-consed-between-gcs) (* 20 (expt 10 6)))
+ (sb-ext:gc-on)
+ (sb-ext:gc))