Re: Strong Typing, Dynamic Languages, What to do?

[Shriram Krishnamurthi <sk@cs.brown.edu>]

One of our list correspondents wrote:

> For the following reasons I think this freedom is bought by a little
> performance-loss:

Thanks.  Let's go over these itemwise, okay?

> - Allocated memory in C is guaranteed to stay in place ... so you can
> have very efficient sorting-routines, for example.

The same is possible with GC.  A copying collector is required to
update the values in registers after copying.  Therefore, a sort
routine that used certain kinds of pointer arithmetic would function
without difficulty.  In fact, compilers sometimes generate "shadow"
pointers to the start of objects if they're going to wander off into
the middle of them.  This is analogous to the sorting situation.

> - Whatever algorithm the GC uses to distinguish live from free-able
> memory-objects, it has to 'look' at every object. The more objects it
> manages the longer this will take -> GC-Time is proportional to number
> of GC-managed heap-objects.

That's why we have generational collectors.  I don't see what you're
getting at.  Perhaps you could explain why you think modern
generational collectors have the problem you attribute.

> - So its better to allocate memory in big parts (like the usual
> efficiency-concerned C-programmer propably does) and not
> little-by-little (like the GC eventually might be tempted to do).

First of all, your "So" is a fallacy.  Collection is proportional not
only to the number of objects but also to the number of references
within the objects.  So just because you allocate a bunch of data in
one fell swoop doesn't affect the collection time.

Anyway, I don't see it.  When you allocate in a nursery, you simply
bump up an allocation pointer.  The real cost is in initializing the
allocated space.  This is the same price you would pay in a language
with manual memory management.  The cost of raw allocation is the same 
in both cases.

> - The more little memory-objects are chopped out of the heap
> (non-contigiously), the longer it will take a 'malloc' to find a
> sufficiently large piece of memory if it is needed.

Yes, and that's not a problem collectors face.  I'm not sure how this
is evidence *against* GC!

> I could imagine that in large programs a robust GC may also lead to
> faster execution because it fights leakage.

There is also precious little evidence that reference counting is
actually faster than modern, generational GC.

Shriram