« Return to Thread: [scala] Collections performance
Re: [scala] Collections performance
by Sean McDirmid
::
Rate this Message:
Comments inlined.
On Wed, Jul 30, 2008 at 5:11 PM, David MacIver <david.maciver@...> wrote:
They share the same implementations. I think making collections work for both mutable and immutable cases has something to do with the slow down.
If the JCL was implemented in cross-platform Scala, it would be as almost as fast as the Java-based JCL. In this case, just take the Java code for the Java JCL and port it to Scala. I don't think we should use different implementations of collections on different platforms (except for interop).
We could take a bunch of collections libraries and port over the best parts (with unit tests). Whether the libraries are mutable or immutable. I guess API affordances would have to be made, but I really don't like immutable features bringing down mutable features (e.g., weakly typed covariant contains method).
I prefer stealing and porting code from other OSS libraries (copying their licenses of course). There isn't much value in implementing another hash map, it probably won't be so fast, someone has done it better, and why bother re-inventing the wheel? Maintainence is a problem though, if we don't understand what we are porting.
Simply OSS license, I don't see the problem.
Right. The fact that the immutable collections library is slower than
the mutable one doesn't surprise me. But the mutable case also seems
substantially slower.
They share the same implementations. I think making collections work for both mutable and immutable cases has something to do with the slow down.
I wonder if it would be worth filling in the gaps in the standard
mutable collection library so that it supports the same interface as
the JCL collections and then using the JCL collections behind the
scenes when running on the JVM?
If the JCL was implemented in cross-platform Scala, it would be as almost as fast as the Java-based JCL. In this case, just take the Java code for the Java JCL and port it to Scala. I don't think we should use different implementations of collections on different platforms (except for interop).
Could do. One of the problems with that, at least if we start from a
.NET or Java library, is that it will most likely enrich the mutable
side of the of the collections API while leaving the immutable side to
languish.
We could take a bunch of collections libraries and port over the best parts (with unit tests). Whether the libraries are mutable or immutable. I guess API affordances would have to be made, but I really don't like immutable features bringing down mutable features (e.g., weakly typed covariant contains method).
One idea I've toyed with is at some point doing a "Data structures
week". Set up a wiki to coordinate and suggest ideas, and have
everyone who's interested pick a cool/useful data structure and put
together as solid an implementation of it in Scala as they can.
I prefer stealing and porting code from other OSS libraries (copying their licenses of course). There isn't much value in implementing another hash map, it probably won't be so fast, someone has done it better, and why bother re-inventing the wheel? Maintainence is a problem though, if we don't understand what we are porting.
Ideally with a set of scalacheck tests and benchmarks for them to work
against. Participants would be encouraged to submit them to scalax or
similar afterwards, but requiring the CLA up front would probably
limit participation.
Simply OSS license, I don't see the problem.
« Return to Thread: [scala] Collections performance
| Free embeddable forum powered by Nabble | Forum Help |
