3 ms·
I'm guessing you are referring this: "2. Don't ever use scala.collection.mutable. Replacing a scala.collection.mutable.HashMap with a java.util.HashMap in a wr
by arete 15y ago
I'm guessing you are referring this:
"2. Don't ever use scala.collection.mutable. Replacing a scala.collection.mutable.HashMap with a java.util.HashMap in a wrapper produced an order-of-magnitude performance benefit for one of these loops. Again, this led to some heinous code as any of its methods which took a Builder or CanBuildFrom would immediately land us with a mutable.HashMap. (We ended up using explicit external iterators and a while-loop, too.)"
Overall Scala<->Java interop is pretty seamless, and aside from some annoying things (for loop becomes foreach with a closure, break & continue are done with exceptions, etc) it's quite easy to treat Scala as a more concise Java with very similar performance.
Rather than using a Scala collections wrapper for the java.util.HashMap he should have simply used the Java HashMap as-is. Yes you must do hashMap.get("key") instead of Scala's shortcut hashMap("key"), but so what? You're talking performance-critical code already, wouldn't you want to avoid the wrapper?
- adgar 15y ago> You're talking performance-critical code already, wouldn't you want to avoid the wrapper? Trivial wrapper classes that just delegate methods to a final ivar should end up inlined.