Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!news.math.psu.edu!chi-news.cic.net!simtel!lll-winken.llnl.gov!venus.sun.com!wnoc-sfc-news!kogwy!math-keio!mad
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: Garbage collection cost (was Re: Parenthesized syntax challenge)
In-Reply-To: clgonsal@undergrad.math.uwaterloo.ca's message of Wed, 11 Oct 1995 17:53:32 GMT
Message-ID: <MAD.95Oct13123618@tanzanite.math.keio.ac.jp>
Sender: news@math.keio.ac.jp
Nntp-Posting-Host: tanzanite
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
References: <44aa9a$j5h@miso.cs.uq.edu.au> <MARCOXA.95Oct4094304@lox.icsi.berkeley.edu>
	<453po8$175@Yost.com> <LUDEMANN.95Oct6140930@expernet26.expernet.com>
	<DGApp8.J41@undergrad.math.uwaterloo.ca>
Date: Fri, 13 Oct 1995 03:36:17 GMT
Lines: 50
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5394 comp.lang.lisp:19472 comp.lang.java:1420

>>>>> "clgonsal" == Carl Laurence Gonsalves <clgonsal@undergrad.math.uwaterloo.ca> writes:
In article <DGApp8.J41@undergrad.math.uwaterloo.ca> clgonsal@undergrad.math.uwaterloo.ca (Carl Laurence Gonsalves) writes:

    clgonsal> The incredible slowness of Java is only evidence of the inefficiency of
    clgonsal> garbage collection. I've programmed in a few languages that have garbage
    clgonsal> collection (among them are Scheme, Modula-3, and now Java), and all have
    clgonsal> been *much* slower than C or C++. I'm not saying Java is bad. ...

You must be joking.  Aside from higher programming cost (for worrying
about memory leak and dangling pointers), malloc/free (or new/delete)
is generally slower than cons/gc because cost of free is proportional
to the amount of objects died during computation while gc cost isn't.

Besides, many implementations of languages that have garbage
collection has cons-aware compilers which opencode data-allocating
operations.

See e.g. the following article and also article in Lisp Pointers
Vol.8, No.1.

In short, if you allocate the same amount of data then memory
management cost should be lower in Lisp than in C.  So having garbage
collection can never be a cause of inefficiency of a language.
(Poorly implemented garbage collector can slows down *an
implementation*, of course.)

In article <KANDERSO.95Oct7105511@lager.bbn.com> kanderso@lager.bbn.com (Ken Anderson) writes:

    kanderso> MALLOC/CONS   5.8  4.0
    kanderso> FREE/GC      25.4  9.7
    kanderso> ---------------------
    kanderso> TOTAL        31.2 14.7

    kanderso> So, CONS/GC is about twice as faster as MALLOC/FREE here.  Object lifetimes
    kanderso> match the assumptions of ephemeral GC quite well here (exponential
    kanderso> lifetimes which are otherwise unpredicatable).  You milage may vary.

If your Lisp program really runs slower than C counterpart, then they
may not be truly `equivalent'.  I often see programmers tend to use
inefficient algorithms in Lisp which they don't use in C; they
generate unnecessary garbages, or they use linear search where it
isn't appropriate.  They stick to APPEND, MEMBER, UNION etc. which
they learned from introductory textbooks.

				--mad
;;;  Keio University
;;;    Faculty of Science and Technology
;;;      Department of Math
;;;		MAEDA Atusi (In Japan we write our family names first.)
;;;		mad@math.keio.ac.jp
