I can admit the whole accessing-non-final-class-fields thing is a bit excessive and can be a over-optimization mental bottleneck, I don't do it often myself. JIT takes care of it anyway eventually, but it's useful to know in select cases - structure generation for example, world.setBlock several thousand times where world is a class field instead of a final local.
The thing is, people often play with ~100 mods, and with that amount of mods a server can be doing millions of field accesses or variable assignments per tick. I dunno if TPS drops are still a problem in modded servers these days - but we've had a lot of custom servers pop up over the years claiming to improve performance with optimized base Minecraft/Forge code, which they did do to an extent - however people still complained about lag and performance, and admins still blamed poorly-coded mods.
Although inefficient packet traffic is probably to blame there too.
I don't really regard anything I said as tricky, it's just base awareness for me. I learned all that stuff early in Java coding though so maybe I'm lucky to have it burned-in. Being an embedded Linux developer probably helps with my performance/memory efficient coding too, though I also admit that I am relatively slow when writing new code.
Grouse yarn, mates! (PSA: That's Aussie for good chat)
I agree. If you want to optimize at a really low level you probably shouldn't be using Java in the first place. Most attempts to optimize the code will probably confuse the JIT more than it will help it. Either way pre-optimizing is a bad habit of getting in to.
Who's doing low-level optimizing? It's just "doing things properly", just like using an indexed list instead of an ordered set when an index isn't needed - as Vic illustrated. Although personally, remembering which List/Set I should be using is far more difficult than remember to declare things as final
Wasn't directing it at anyone ;), I definitely agree that final where possible is good practice. Lots of new languages have immutable by default which is helping. Most stuff that can really improve Java's performance usually involves tip-toeing around the GC (String concatenation, object pooling etc.). Knowing what data structures to use IMO feels more like general computer science.
I've personally never used a Set, no idea if I should be in anything I've done. There are so many types of collections it does my head in. If what I need to do can't be done in an Array then I just use a List. I'm sure the JIT can cache the lookups of Lists too, right? Still, I've got a feeling I'll one day have someone see my code and ask "Why aren't you using a Set/Map here instead"
Mmm, good technical explanation. I often (nearly always) use ArrayLists as my initial choice for building datasets of unknown size and where it's inefficient to count the number of required entries beforehand (otherwise I use an Array). I also often take advantage of the insertion and collection sorting of ArrayLists, where an ArrayList is holding custom objects - simulating a database-like functionality.
So in summary - ArrayList is best where random access is expected, and especially where random writing/inserting is *not* a factor - whereas a LinkedList is better for serialized access and dynamically changing content?
Is either List better or worse for sorting via custom comparator, where the comparator works with fields on the List's objects? Based on what I've learned, I'd assume HashMap - if so, what's the better trade-off if you need both regular random access and regular re-sorting of a List? Something completely different?
Cool, good info. So as i thought, ArrayList is a good start when you're not sure how it's going to be used - it's pretty capable so yeah. I'll have to do some reading and maybe look at samples where a LinkedList is ideal.
I could guess that LinkedLists (or three, one for each x/y/z dimension) would be good for holding a bunch of blocknames when you're generating a procedurally generated structure - I'm sure I'll see the sense in that once I eventually work on such code (and will read more about LinkedList at that time).
*We* always hijack? I always start these haha.
Well, the user has gotten quite a few solutions - and the question does belong in the topic of "good coding and best practice" so it's semi-related. Not unrelated-enough to go and bother with IRC or open a new topic anyway as far as I'm concerned. It's good in-case a newbie comes along and sees this thread, and learns a few tips from our ranting
I've never heard of having multiple dimensions of linked lists before Since Java's LinkedList implementation are doubly linked lists, they can function as both a queue (FIFO) like vic_ said and a stack (LIFO). The downside of this however is that it uses more memory overall (each node has two references).
So I don't think they'd fit that well for storing multi-dimensional data. An ArrayList or a normal array with predefined size as something like new Object[x * y * z] would probably be better.
Oh yeah, a list of co-ords + data would need more than three arrays xD
So a three dimensional array of a large size (e.g. ) for when you're parsing structure plans from an external source isn't such a bad idea after all? If they're instanced locally, or the 3D array is static...