[H-GEN] Which is better?

[Andrae Muys]

Russell Stuart wrote:
> [ Humbug *General* list - semi-serious discussions about Humbug and     ]
> [ Unix-related topics. Posts from non-subscribed addresses will vanish. ]
> 
> On Tue, 2004-04-27 at 14:20, Harry Phillips wrote:
> 
>>First part:
>>The difference is so small that there is no difference.
>>
>>Second part:
>>The compiler is very clever, just use it, if the code gets slow then 
>>worry about it.
> 
> 
> You learn quickly!  On machines that run Java, this the correct attitude
> to have.  In Java and similar languages the greatest overhead comes from
> their memory management.  Whereas C/C++ place most things tend to be
> placed on the stack or made static, in Java everything and its dog
> requires a call to the memory allocator.  This completely overshadows
> the sorts of optimisations you were trying to implement.  If you want a
> "rule to code" by to make java run quickly use this one: keep the number
> of objects you create and destroy to a minimum.
> 

This is flat out wrong; and a good example of the sort of dodgy 
practices associated with premature optimisation.  With a decent GC 
implementation heap allocation in a language without pointers is fast.

Keep the code simple.
Get the code correct.
Measure.

The normal culprits for code inefficiency are:

1) Poor choice of algorithms.

2) Poor IO handling.

3) Thread-synchronisation/Memory Allocation/Cache thrashing in inner-loops.

I have spent the past 6 weeks doing full-time java optimisation. 
Although I am fully aware that code I have written to speed up sections 
of code include thousands of unnecessary allocations, removing them 
isn't even on the radar yet.

Eventually I know those allocations will float to the top of the 
profile.  When they do, I know how to remove them.  In the meantime they 
make the code substantially easier to read and understand --- and 
correspondenly more reliable.

Now in line with suggestions that I provide help for people wanting to 
get a better grasp of what's happening behind-the-scenes, I strongly 
recommend reading the following three pdf's.

Garbage Collection Can Be Faster Than Stack Allocation
http://citeseer.ist.psu.edu/appel87garbage.html
    - Misses a few important concepts from his analysis (esp. the lack 
of discussion about locality), however the concept that Heap Allocation 
need not be substantially more expensive than Stack Allocation is sound.

Simple Generational Garbage Collection and Fast Allocation
http://citeseer.ist.psu.edu/appel88simple.html
    - A short paper providing a quick summary of Mark-Sweep and Copying 
Generational GC

Uniprocessor Garbage Collection Techniques
http://citeseer.ist.psu.edu/wilson92uniprocessor.html
    - A much longer paper, but can be read by section.  Covers a number 
of different algorithms; including incremental, and conservative (ie. 
works with C/C++) collectors.  Also includes discussions on locality, 
and implementation issues.  Estimates the cpu-cost of GC to be ~10% and 
the memory-cost a factor of 2.

Andrae Muys