Scala 2.9 vs 2.10 Performance
markehammons.wordpress.com
markehammons.wordpress.com
Could somebody familiar with the changes to 2.10 explain where the performance boost came from and what code it will affect? Does this make Scala a more compelling choice for the discerning functional programmer?
What I'd really like to see is faster compile times. I know it's a tall order given the complexity of implicits, but compared to other languages Scala compilation slowness can be a tough sell.
At any rate, if you really wanted to compare, you would have to run the benchmarks on the same platform, i.e. Dalvik on the desktop or HotSpot on Android.
Which makes no sense either.
What they are designed for and what they are quite commonly used for are different things. Both are used for running my application code. Serious performance problems on one makes that worse, regardless of whether it is worse-as-designed or not.
WinRT has built in support for reference counting now (both in run-time and in its libraries); that's a big deal for mobile! Sure, the collector is still present and you can use it in C#, but...the game is changing quickly. Apple, of course, supports reference counting already, Dalvik does not as there is no easy way to bolt that onto Java (though I wouldn't be surprised if Google eventually does what MSFT did with WinRT).
Disclosure: MSFT employee and general programming languages hacker.
I'm just guessing here, but I believe, if anything, Dalvik is better at those.
That seems to be a Scala problem, not a Dalvik one.
Dalvik is a JVM that's extremely optimized for one specific purpose: running on mobile phones. And it's doing a fantastic job at that.
It's an okay JVM at best, and it's a pain in the ass to deal with because of its lack of support for things that are at this point basic on the JVM, i.e. code generation. And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit--which, in addition to making Groovy, Rhino, etc. unusable, hobbles Scala, too, and will hobble Java 8 when that comes out.
We're talking technical here and you're throwing in a legal argument?!? What does this have to do with the implementation of the JVM?
> And it's not just the different-to-be-different bytecode environment that does that, but bad design decisions like a laughably low class limit
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
"Be different enough to not get sued" is a technical requirement as well as a legal one because it informs the design of your product. For example: the use of a different bytecode format in Dalvik pretty obviously had much more to do with "we can't make it look like a real JVM because we'll get sued" than efficiency; it's not a significantly better format than the standard Java bytecode system and using it trashes your compatibility with common Java libraries and tools.
Obviously, you are an expert on virtual machines and the Android team should listen to your wisdom.
Good ad hominem, bro. How's that working out for you?
I am not an expert, no, but I do know a few things about them and I know a few more about application development, on Android and off. Dalvik is not a good citizen of the Java ecosystem (as evidenced by its inability to do things that are considered very normal, i.e. Groovy or Rhino for scripting). You can't do really basic stuff like LiveConnect because of the twin fails of no bytecode generation (there's no dexer on-device) and, as mentioned, the class limit does a number on Scala and will hose Java 8. These are technical problems that stem from decisions made during the design process, and they're not edge case problems--well, the Scala bit is, but you can surface the same problem by just having a lot of dependencies that pull in a lot of class files.
When you're talking JVMs, you must compare to HotSpot because that's the main game in town. Dalvik doesn't compare well the design decisions inside of Dalvik serve to hobble developers who are not looking to write very simple, Android-idiomatic (which is not Java-idiomatic) CRUD apps. And that sucks. I would like it to be better. It isn't at present. I don't hold out a lot of hopes for improvement, though I would like to be wrong.
Just kidding. The initial Scala compiler was written in Java. After that was working, they rewrote it in Scala using their initial Java compiler, and then it became the process I mentioned.