Performance/Memory

[GoogleCodeExporter]

This issue should be used to track performance/memory improvements as they
are discovered.

Theres a bunch of garbage created for maths computations atm. This makes
the code easy to read but it might help tidy this up a bit.

Performance wise the important one seems to be reducing the complexity of
the Box/Box code. However, this is ported from the original demo so ways to
speed it up arn't immediately obvious.

Original issue reported on code.google.com by kevgl...@gmail.com on 5 Aug 2006 at 4:54

[GoogleCodeExporter]

I found some performance issues at handling of "Arbiter".

* because creating a "Contact" is expensive
  + changed update() method using ONE Contact for merging instead of an array
  + moved init of contacts-array to collide() (from constructor)

* calling contains() and remove() very often is expensive on a List
  + used a better hashCode() at Arbiter and a HashMap at CollisionSpace instead of
ArbiterList
    - changeing this it was necessary to change the World

Original comment by DannyLade on 12 Jul 2009 at 11:32

Attachments:

• Arbiter.java
• CollisionSpace.java
• World.java

[GoogleCodeExporter]

A very small performance issue:
Methods which are very often called should be "final" - the java VM can call 
them
faster because there are no inheritance checks necessary.

I used this knowledge on Vector2f.

Original comment by DannyLade on 12 Jul 2009 at 12:07

Attachments:

• Vector2f.java