Ah so it only works without an iterator for primitive arrays, got it.
Looking at the source, that looks like it makes a new instance which doesn’t sound great for doing often either.
Best option would be to get the actual arraylist array however longer it may be and iterate through it up to the actual internal size value. But I doubt that can be done with a foreach.
Edit: Although I see now it’s that way because the list you get is safe from outside manipulaiton. I guess that’s one thing that needs this trade off.
It only creates a new array (or list) as needed. If you add a bunch of things, it acts like an array list. If you then iterate a bunch, it creates an array one time.
So it works especially well for stable things like… child spatials, controls, listeners, etc… 90% of the things you might want to iterate often and not create garbage.
The fact that you can modify the list while iterating is also a nice benefit which is required for things like child spatials, controls, listeners, etc… not a coincidence.
(Anyone iterating over a regular list of listeners is looking forward to a bad time someday.)
My hope for value types is that it it’s a first step on the way to being able to have a java-array that you can send to native code. So that java devs does not have to use misc.Unsafe or NIOBuffers to talk to the graphics card. Now Valhalla does not have this goal but a predictable memory layout of value types is at least closer than what we have now for arrays
I suspect that an array of structs and an array of objects will have just as predicable a memory layout in the end.
…else there are a LOT of changes they are going to have to make to wedge structs in and have them not be treated at all like objects. I guess we’ll have to see.
Yeah I should have said predictable and compact. The goal of Valhalla is to make an array of 'struct { int x, int y} ’ have the memory layout ‘(header),x1,y1,x2,y2,x3,y3…’ .
this thread contains a lot of valueable information, thanks!
Makes me think it would be nice to have some kind of “Java Performance for Dummies” wiki page
Could someone elaborate if this container would have benefits to engine users for actual in-game systems and the like? If I understand correctly this would be vital for multi-threading isn’t it?
It is useful for anything you want to iterate over a lot.
For example, SiO2 uses it in its EntityContainer class and so I use it all the time in my game code.
You will have a bad time using SafeArrayList for this because it’s not thread safe. We didn’t want to add the overhead for that when there is already CopyOnWriteArrayList provided by the JDK for thread safe lists… it just doesn’t expose the array. But you are already sharing a list across threads so maximum iteration speed is usually not an issue then.
For all the argument about memory and performance, intelligence is the underlying factor in most cases; education will outperform an uninterested c++ programmer all day long. I enjoy using java. I like a lot of languages.
Edit: I do enjoy a good constructive discussion, though. There are some highly skilled individuals amongst us.
It’s critical for android. It’s still faster for desktop and creates less garbage… while the garbage is essentially free on desktop in this case, “essentially free” is not “free”.
If you can get the benefits without any extra costs then why not do it?
I use SafeArrayList a lot… but I would. I wrote it.
