downs: >and its thoroughly object-oriented design forces heap access that is often >unnecessary for solving the problem;<
In D/C# you can use an array of structs that sometimes allows for better performance, in Java to avoid the decrease in performance caused by using an array of references you may need to use several parallel arrays of the single fields of the struct. But the cache coherence signature of such parallels arrays is different, sometimes it's better and sometimes it's worse than the array of structs. If you have to access several items at once of each struct of the array, then using the array of structs is generally faster than using the parallel arrays. If you have to scan only one or few fields then using parallel arrays is faster because there's less data that comes through the caches. Time ago someone has created a "parallel array" struct here to allow for such layout choices at compile-time. A VirtualMachine in theory can dynamically change such struct/array layout at runtime according to the access patterns to the data :-) I think similar dynamism in data structures may be done in the next generation of VM-based languages (you can implement such smart data structures in D too, but the data structure has to be mostly opaque and you have to forbid taking addresses to any data, because it can be moved and shuffled around). >Um, he said he hides the bad results _for Java_.< Right. I generally don't like to hide things, and I show all data I have collected. Sometimes I don't show benchmarks where Java looks slow because they can be boring and because I am not currently interested in improving the JavaVM. Focusing on where LDC/LLVM do badly I can try to improve them. Bye, bearophile
