Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: Memory Management in Lisp? Message-ID: <1991Mar8.000215.21918@Think.COM> Date: 8 Mar 91 00:02:15 GMT References: <1991Mar5.040348.25396@Think.COM> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 27 In article pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: >If your attitude were right, then why bother with any sort algorithm >other than bubble sort? It gets the job done, and if it is too slow, add >more CPUs (actually a quadratic number of CPUs :->). [Look at what company I work for -- we *do* add more CPUs :->] It's been a long time since I've had to write a sort subroutine, but I think 90% of the ones I've written have been bubble sorts. I depend on the environment providing a sorting function that has reasonable performance. Similarly, I've never written a routine that optimizes disk r/w head motion; if the OS doesn't optimize it, it doesn't get done. If it's easy to optimize something in my code and it doesn't obscure the structure, I'll do it. For instance, I use NREVERSE and NCONC when it's clear that the old structure of the list can be reused (generally when it is a newly-consed intermediate value). I'll use Symbolics's STACK-LET (in ANSI Common Lisp this will be the DYNAMIC-EXTENT declaration) for local temporaries in an inner loop. Other than simple stuff like this, I don't believe in heavy source optimizing except for major bottlenecks. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar