4 ms·
Every time I've used Scala collections, they've behaved exactly how I'd expect them to. What parts of the collections perform poorly?
by octo_t 13y ago
Every time I've used Scala collections, they've behaved exactly how I'd expect them to. What parts of the collections perform poorly?
- kasey_junk 13y agoThe scala collections (even the mutable ones) generate tons of garbage (e.g. getting a value out of a map automatically creates another new object). Scala hashmaps (even the mutable ones) are much slower than equivalent java collections.
- thescrewdriver 13y agoIt seems that the performance difference has little to do with temporary objects, but is to be fixed 2.11 anyway: https://groups.google.com/forum/#!msg/scala-internals/Fw37NmUUiqs/k9jxMXDYEhYJ https://groups.google.com/forum/#!msg/scala-internals/Fw37Nm...
- sukaka 13y agoA recent comparison was made with scala and java collections. Lots of interesting tidbits. http://www.takipioncode.com/2014/01/23/java-scala-guava-and-trove-collections-how-much-can-they-hold/ http://www.takipioncode.com/2014/01/23/java-scala-guava-and-...
- ionforce 13y ago> getting a value out of a map automatically creates another new object Do you have a code sample for this?
- kasey_junk 13y agoFrom MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value } From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
- azth 13y agoOut of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.
- kasey_junk 13y agoNot sure how familiar you are with the Scala syntax, but that code actually has null pointer problems. The apply function turns Options into null pointers. They've given me the worst of both worlds, not only do I get null pointers, I get to have extra garbage created to accomplish it.
- azth 13y agoYep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?
- kasey_junk 13y agoI actually have no problem with the extra allocations if they maintain safety (that's not quite true, I actually need to break safety occasionally). The problem is that the incoherent design of the collections library means that it is not clear to the programmers of the default mutable hash map lookup what they are striving for. If they were striving for performance they would use a model that allowed for NPE against safety, that had allocation semantics that were sensible. Conversely, if safety was the overriding concern they wouldn't allow for the NPE. Instead, in one of the most central data structures of the language we get unreasonable behavior. This is clearly a sign of bad design, thus reputing the original assertion that the Scala collections library were a good example of type programming. PS: To trivially answer your question, they should have inverted the implementation here. A NPE throwing method for lookup wrapped with option sugar would make way more sense than the inverse.
- azth 13y agoMakes sense, thanks for your answer :)
- dk8996 13y agoI hate to call you out on this but look at the collection hierarchy and tell me its not complex. http://docs.scala-lang.org/resources/images/collections.mutable.png http://docs.scala-lang.org/resources/images/collections.muta...
- thescrewdriver 13y agoDoesn't look very different from the equivalent diagram for Java. Have you seen how many different collection classes and interfaces there are in the Java standard libs? AbstractCollection AbstractList AbstractMap AbstractMap.SimpleEntry AbstractMap.SimpleImmutableEntry AbstractQueue AbstractSequentialList AbstractSet ArrayDeque ArrayList Arrays BitSet Collections Dictionary EnumMap EnumSet HashMap HashSet Hashtable IdentityHashMap LinkedHashMap LinkedHashSet LinkedList PriorityQueue Stack TreeMap TreeSet Vector WeakHashMap ArrayBlockingQueue ConcurrentHashMap ConcurrentLinkedDeque ConcurrentLinkedQueue ConcurrentSkipListMap ConcurrentSkipListSet CopyOnWriteArrayList CopyOnWriteArraySet DelayQueue LinkedBlockingDeque LinkedBlockingQueue LinkedTransferQueue PriorityBlockingQueue SynchronousQueue BlockingDeque BlockingQueue ConcurrentMap ConcurrentNavigableMap TransferQueue Collection Deque Iterator List ListIterator Map Map.Entry NavigableMap NavigableSet Queue RandomAccess Set SortedMap SortedSet I've worked with both Java and Scala collections classes for years and I strongly prefer the Scala collections. If you prefer the Java collections they work just fine from Scala too.
- kasey_junk 13y agoThat is just the "published" hierarchy as well. Paul Phillips likes to pick on the ParSeqViewLike trait, and if you ever find yourself delving into it, you'll see why.
- thescrewdriver 13y agoAs someone who actually writes production code in Scala on a daily basis Paul Pillips' "concerns" have had zero practical impact on my daily use of the language. I tried to find content in his presentations that actually had any impact on me but I couldn't.