Subject: Re: C++ briar patch (Was: Object IDs are bad) From: Erik Naggum <erik@naggum.no> Date: 1997/05/15 Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ Message-ID: <3072689658775455@naggum.no> * Harley Davis | In my experience, the real killer with Lisp is not so much raw speed, but | rather excess memory use. in my experience, Lisp systems start out with a couple megabytes of memory to hold the entire run-time system, then grow very gradually and maintain a low system profile as far as memory goes. C programs that do any useful amount of work grow rapidly and remain large after the allocated memory have outlived their usefulness. they even leak memory when run over long periods of time. the real difference between Lisp systems and C programs under Unix is that the Lisp systems usually do their work in one long-lived process, whereas the Unix way is lots of short-lived processes. C's memory allocation is well suited to this mode of operation, since the operating system does the garbage collection when the process terminates. however, the C++ way with Windows is once again large, long-lived processes. not surprisingly, C++ does _much_ worse in this department than Lisp systems generally do. furthermore, if memory usage was a "killer", Microsoft would never have been able to hoist its disgusting inferiority on the world. even simple tools like e-mail clients for Windows use more memory than computers _had_ only a few years ago. Lisp systems _were_ relatively large, but since they haven't grown very much, they are now _small_ compared to the cancerous growth of software written by inferior programmers in inferior languages. #\Erik -- if we work harder, will obsolescence be farther ahead or closer?