"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?
"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?