I don't know 100% for sure, but if something's built on top of arrays, it's not going to be faster than an array. You can't get faster than the thing you're using. If it has extra index information, that's going to slow it down because it has to process, keep track, etc. that index information. Arrays in ASM, if my memory serves, is literally implemented and moved via memory (ram) jumps. In computing, the only things faster than ram jumps and reads are register reads.
I should also mention that predetermined size is a bad idea in this particular case. While good for reads and jumps, you don't want a case where you'll need to constantly resize the limited array as that will, usually, quickly overshadow and performance gains. And since we don't know the max size of all possible events (now and in the future), nor do we want to pre-set an absurdly large size for all eternity, it's better to stick with an expand-able array for now.
With that said, something compiled to a binary doesn't guarantee it's speed. It only, sometimes, guarantees that the interpreter doesn't have to re-translate/compile it down asm code again (sometimes because Java binaries still need to run through a java machine). Optimized also don't guarantee a speed up. It's just written in a way to trim down read and/or run time and/or use different techniques to try to run the fastest version of an algorithm for the situation.
I'm writing the above just in case you have the common misconception that optimized code can run better than barebones code or a different data structure that is closer to solution of the problem. I once knew someone that though that the array optimization in javascript would make array searches as fast as or faster than a hash look up. I ran some tests to find that, while it is fast, direct hash look ups are faster. And that guy wasn't dumb nor a bad programmer, but these misconceptions do pop up in this tech industry.
