I want to spawn a stack of 12 puzzle pieces randomly, what I want to be able to do is pick (x) number of pieces from a stack of 12 pieces and spawn both of them. The x number of pieces are going to be removed and randomly spawned, while those that are left over will be spawned at their original positions on the target play.
So I was looking through the Unity Answers yesterday and found that many people recommended using List instead of Arrays, but I’m not very proficient at using Lists yet, should I just stick to Arrays?
It’s important to note that List is just an abstraction over the top of array(s). Lists internally use arrays to store their data. They start by allocating an array and every time it fills that array it doubles it’s size so arrays are definitely more efficient when you have a fixed length. That being said, you can also specify “capacity” for a list, so if you say:
var mycollection = new List<PuzzlePiece>(12);
The above will allocate an array with a capacity of 12 internally. You performance hit for using a list in this case will be almost zero since you can still access it via index and you do get some other nice features that could be used if needed.
The performance hit is actually quite substantial for some reason, at least for primitive types and structs (much less so for e.g. GameObjects etc.). Arrays can also be easier to deal with in some cases, e.g. if you do
var foo = new int[12]
then you have an array with 12 actual entries, without having to manually add them (or remember other techniques for filling lists with values), which are all initialized to 0, so you can always do “blah = foo[5]” and know for a fact that you will never have issues like possible null reference exceptions.
@DustineHorne tha’t’s a very good tip, but for my project, due to the simplicity of it, I’ve stuck with the use of Arrays instead of List, maybe I will be able to use Lists next time, but it’s still quite complex to me as of now.
Completely depends on what you’re doing. If you have a static list that is populated once and you’re accessing values by index then there is no difference. Only when adding the items do you see a difference. However, if you plan to loop over the results, regardless of whether you use “for” or “foreach”, the List performance will be substantially worse, though on 12 items if you’re not doing it thousands of times per frame, it would be inconsequential. The reason for this though is because the compiler optimizes away the bounds check on an array in the event of a for loop. Even accessing as single element has the issue where the List does the bound check twice (the indexer on the List does it once and the underlying array will do it again) but it’s not a noticeable difference unless you’re doing a lot of it. However, in the event of a for loop, only the bounds checking of the underlying arrays get optimized away and they still happen on the List itself, which results in lower performance regardless of the type of T.
There may be other considerations as well, that’s just the major one I’m aware of.
No, sorry, there is a substantial difference. I don’t know the reason, but it’s very pronounced and measurable, up to 500% or so (again, for primitive types/structs, much less so for complex classes). Repeated profiling and benchmarks led me to essentially re-implement Lists using arrays for Vectrosity because of the performance gain, and the same for LinkedList in FlyingText3D. Remember that Unity uses Mono, and an old version at that, so .NET theory doesn’t necessarily apply.
I was going to mention that as well… the implementation for one is probably a little different in Mono, but I think they key factor is the compiler (and runtime) which, given the data version used by Unity, probably provides far less optimization than modern iterations. At any rate, I agree with you… if it’s practical to use arrays you should always do so from a performance standpoint.