Hacker News Reader

Comment by octo_t | Hacker News Reader

Every time I've used Scala collections, they've behaved exactly how I'd expect them to. What parts of the collections perform poorly?

View on HN

The 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.

A recent comparison was made with scala and java collections. Lots of interesting tidbits. http://www.takipioncode.com/2014/01/23/java-scala-guava-and-...

It 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/Fw37Nm...

> getting a value out of a map automatically creates another new object

Do you have a code sample for this?

From 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) }

Out of curiosity, how would you rather have them be implemented? You either return an Option, or you will have to deal with null pointers.

Not 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.

Yep I get that point. However, how would you avoid extra allocations and maintain safety (no nulls)?

I 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.

Makes sense, thanks for your answer :)

I 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.muta...

Doesn'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.

I looked at it and understood it in a few seconds. What about it do you find complex? It looks like a well organized api to be honest.

What is wrong with that? There are three core data structure types (maps, sets, sequences), and variants of those depending on need. Most of these are standard data structures you would find in an undergrad textbook.

That 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.

As 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.

As someone who also writes production code in Scala on a daily basis, and who took exception to the idea that the Scala collections library was a good example of type programming, Paul Phillips' concerns are spot on.

If you are using the collections library as example of how to structure your own code, you are in for a bad time. The abstractions are not right, and things like the silly ParSeqViewLike trait are an expression of that.

In day-to-day use I haven't run into any of these issues. Your mileage may vary.

Reply on news.ycombinator.com