On 04.01.2011, at 00:01, Sean Luke wrote:

On Jan 3, 2011, at 4:31 PM, Matt L. Miller wrote:

It boggles my
mind that any structure that (I assume) uses arrays to back it is faster
than direct access to an array; how often does that happen?

I'm guessing it's a memory fence issue on compiling of some sort.  At any rate, it appears that if you have an array as an instance variable in YOUR class, then accessing it in a method is faster
than someone externally accessing it even if it's public. At least in Java 1.6, HotSpot, OS X. Anyway, seriously, in the goofy little microbenchmarks I've written that's exactly what I'm seeing.  ArrayList can now sometimes be faster than accessing Bag's array directly.

Sean

As long as there are no considerable speed improvements leave it the way it is. In actual simulations I don't expect any major speed improvement because the items of the Bag object will be accessed and usually some more (complex) computations will be applied to these objects. The part of fetching object references will not have any major impact on simulation speed.

If the MASON library should be modified to use ArrayList I think the main problem is the well documented 'design flaw': Unlike Vector or ArrayList, Bag is designed to encourage direct access of the array. Well, that leaves not very much room for interpretation or a subtle change.
As Matt previously mentioned using the deprecated flag might be an option for later use. In future MASON versions the direct access to numObjs und objs might be restricted to "encourage" the user to access these fields by a getter method. This will break up existing code only in a simple manner (Object[] objs = bag.getObjs(); instead of Object[] objs = bag.objs;) and might allow to shift to ArrayList, e.g. building a wrapper class or inheriting the Bag class from ArrayList. 

Summary: On one side there might(!) be a slight decrease of speed using Bag but having still compatibility to all simulations, on the other side a possible(!) small(!?) amount of speed increase and breaking up with compatibility.

I think recoding simulations will cost much more time than it might be saved during runtime using the optimized ArrayList execution.


But if you desperately want to modify MASON to use ArrayList instead of Bag in future releases ("use this script for success"):
1) Add the public methods
Object[] getObjs()
and
int numObs()
2) Encourage the users to use these methods instead of direct access to the field.
3) In the documentation tell the users it is a bad idea to directly access the fields because of future compatibility (and it is not part of good oo design).
4) In a future release declare these fields private (desperate users might build their own MASON library with these fields being still public).
5) In a future release replace the Bag class by a ArrayList based Bag class that offers the same speed increase as ArrayList. This Bag class may return an ArrayList object hence the user will get used to ArrayList.



Jörg