2011/7/5 Cédric Beust ♔ <[email protected]> > One more thought about: > > > the need to create a loop when performing a trivial mapping over some > collection > > As you may or may not know, there is a pretty bad performance problem with > for comprehensions in Scala at the > moment<http://stackoverflow.com/questions/6146182/how-to-optimize-for-comprehensions-and-loops-in-scala>, > and it's > severe to the point where the only workaround at the moment is to fall back > to writing an imperative while loop. > > This is at best a misunderstanding of the problem and, at worse, active misinformation (a.k.a. FUD)
Just to make the point clear, this is NOT a bad performance problem with for comprehensions. It's a bad problem with explicit return statements when used within a for-comprehension over a range - a much more specific (and rare!) combination of factors than your email implies. The correct workaround is not to use a while loop, but to avoid the return statement. Not that big a deal, as return statements are typically considered bad form in Scala anyway. I have absolutely no belief that any malice was intended here, and can understand *why* this misunderstanding would occur. In older versions of Scala, using a comprehension over a range *would* be much slower than the equivalent loop, even without the return statement. Martin was previously opposed to adding a special-case optimisation for this specific case, as ongoing virtualisation efforts can effectively solve it, and it adds a tax payable on all future work in the compiler. There's also a performance enhancer available that's more potent than loops. Scala can perform tail-call optimisation, so if the functionality had been written using recursion, then the emitted bytecode would use a simple jump and be even faster. Better still, the technique can be combined with specialisation and to avoid the performance cost of boxing and unboxing in generic code. This is a classic scenario in which Scala can readily outperform Java. Ultimately, Martin bowed to community pressure, and the optimisation was quickly added. For comparison, lets take some frequently demanded features for the Java language and see how Sun/Oracle responded to the community pressure. These aren't mere slowdowns either, but real showstoppers that can fundamentally damage the expected behaviour of your code. 1. Unstable enum hashCode; The hashCode of an enum changes between JVM runs and on different machines. This is a real killer if using hashed indexing alongside persistence, or in a shared cache. Reported 2006, closed as low priority/will not fix: http://bugs.sun.com/view_bug.do?bug_id=6373406 (assuming the site isn't down again) 2. The definitions of equals and hashCode in the URL class make a DNS lookup call, they're defined in terms of the current state of the internet! This is a real classic, anyone who's found Eclipse hang on them when opening the update manager whilst not online... this was the reason. To the best of my knowledge, this still hasn't been fixed in JDK 7: http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html 3. Tail-Call optimisation, for which a *working patch* was submitted to the OpenJDK in 2009. It may arrive in JDK8, but I wouldn't hold your breath: http://weblogs.java.net/blog/forax/archive/2009/12/18/tailcall-anyone It's really starting to look as though Java isn't fundamentally any better than Scala, C++, or almost any other current mainstream language when it comes to being a standard bearer of suitability for enterprise use. This is the kind of tiny detail that can totally wipe your argument from > several angles: 1) for comprehensions are great but you should avoid them if > you need performance (so Scala's performance is not on par with Java's after > all), 2) it shows the immaturity of the compiler (you claim both the > compiler and the tools are mature) and 3) this is reminiscent of C++, which > was riddled with this kind of weird behaviors resulting from the interaction > of the crazy amount of features that the language supports. > > -- > Cédric > > > > > On Mon, Jul 4, 2011 at 11:33 AM, Mario Fusco <[email protected]>wrote: > >> Hi all, >> >> inspired by a discussion we started on this mailing list a few weeks >> ago, I blogged my thoughts about why in my opinion the adoption of >> Scala is a winning decision especially under a business point of view: >> >> http://www.mate.it/en/component/content/article/84-perche-scala >> >> I hope this could reopen that discussion by bringing new ideas and >> clarifying the old ones. >> >> Cheers, >> Mario Fusco >> http://twitter.com/mariofusco >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright gtalk / msn : [email protected] google+: http://gplus.to/thecoda <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
