Warp wrote:
> reason memory allocation speed is not something which has been optimized
> to death in C(++) compilers, for whatever reasons 

I'm suspecting it's because C and C++ use pointers rather than 
references, and can't carry around enough metadata (generally speaking) 
to allow finding the pointers in a data structure, so they can't compact 
memory. That means that finding free memory is generally a search.

> There's nothing in GC in particular which would make allocation
> faster. 

Generally, yeah, there is. Allocation of a structure in a compacting GC 
implementation is almost always as fast as allocating something on the 
stack in C++. When it isn't, it's because you have to run a compacting 
GC cycle first.

> It's just that GC engines have been more optimized for allocation
> than most C(++) memory allocators.

That's what I said.

>   I have to admit this is a shame to C and C++. OTOH, it cannot be blamed
> on the languages, but on the compilers and their libraries.

I'm not sure that's 100% true.  Often, taking a big program with a 
hand-crafted allocator just for that program, and replacing it with a 
GC'ed memory allocator, will actually run faster.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message