I was benchmarking an algorithm I wrote that uses List to aggregate small values in prepend only, List is the ideal structure for this. Turns out 45% of my time is spent on this (measured with JMH+JFR)
Now I don’t use ListBuffer and never had, I don’t know who does and I imagine this is impossible to take away at this point, but would it be possible to add a runtime flag (one of those System properties) that disables this for those that just don’t use ListBuffer?
For my case this is so painful I’m considering rolling my own cons+nil list, which is a terribly thing to do…
“It turns out to be hot code and all I need is a simple data structure with limited features” is fine.
The use case makes me wonder: usually I want to start with the least powerful thing and then grow if necessary, but the standard library really supports starting with the most available thing.
When performance is critical, I avoid all built-in collection classes of Java and Scala as much as possible and fall back to the primitive arrays.
By the way, my work involves high-frequency trading, and for a sizable portion of the code performance is absolutely critical.
Even if you do not want to design your data structure from the ground up, it may still be sensible to redesign the critical path. For example, you can make a wrapper around List, that reimplements map, filter etc (limit it to the ones you really need) which just builds a new list in reversed order every time you call a method. Keep track of the number of calls. If it is even, the result is already good, otherwise you reverse on read. If you know the max number elements on beforehand, using an encapsulated array is also a good option, as @eastsun indicated.
This shows that, with knowledge of the problem area, you are always able to make a collection that outperforms the standard collections. But it is an unfair comparison, those collections are designed to be have a decent performance in most circumstances.
