Interesting speed benchmark

[Delaney, Timothy]

> As one poster suggested, Python's reference counting might be the 
> culprit, so I modified the Java test as follows (probably not the 
> correct way to do it):
> 
> public class ObjectTest {
>      public ObjectTest next;
>      public static void main(String[] args) {
>          for (int i = 0; i < 1000; i++) {
>              ObjectTest root = new ObjectTest();
>              for (int j = 0; j < 10000; j++) {
>                  root.next=new ObjectTest();
>                  root=root.next;
>                  System.gc(); // <-----------Force garbage collection
> 
>              }
>          }
>      }
> }

Actually, just as a note, System.gc() will not *force* a garbage collection,
but gives a hint that "now would be a good time for gc ...".

If your thread is running at a higher priority than the gc thread, it's
likely that no gc will occur anyway.

However, it seems on your JVM that gc is getting the chance to run.

BTW, it's not so much Python's reference counting which is the overhead, as
what happens when the references to an object reach zero, which is what
happens in your algorithm. As you set

	root = root.next

each time, the old "root" drops to a refcount of 0. As a result, the object
is destroyed.

This has both advantages and disadvantages. The disadvantage is that it
takes a little bit longer each time throught. The advantages include:

1. You know *when* the object will be destroyed (in a program a trivial as
this).

2. Since you only ever have 2 ObjectTest instances at any time, it's highly
likely that the memory for them will be reused for the two instances,
meaning you don't have to continually allocate more memory. This means thr
program is more likely to run in a smaller memory footprint - always a Good
Thing (TM).
Tim Delaney