4 ms·

Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very dis

by sixbrx 10y ago

Is the excessive virtual dispatch still really slowing down simple for loops in Scala? I thought Paul Phillips did a special-case fix for that. That's very disappointing if that's still a problem. When I programmed in Scala, I felt like this sort of thing showed that priorities weren't quite right in the leadership somehow. For-loops are pretty basic and their performance is important - simple ones shouldn't have ever been slower than the equivalent Java ones IMO. Another instance of misplaced priorities (again IMO), was the problem that you couldn't have local/temporary variables in your class constructors (see for example http://www.scala-lang.org/old/node/1198.html http://www.scala-lang.org/old/node/1198.html). Any values that you created inline in your class body (which is your primary constructor) could be used but would implicitly become fields in your class instances even if they were never used in any methods. Sure you can make factory methods in a companion object etc but should have to do that always? That's worse than Java and for no good reason! The "simplified" syntax of not having an explicit block representing scope for the actual constructor code, separate from member declarations, really bites in this case. An example of this was the gcd value in Oderski's rational number class which is one of the first examples in his book. The gcd value is needed to initialize the numerator and denominator values, and you want to save it after it's first computed temporarily so you don't have to compute it twice. But naming it at all made it an actual instance field, not just a temporary in the constructor. So every Rational would be carrying around this significant extra storage unbeknownst even to a programmer who would have reviewed the source code, unless they are in the habit of examining javap output for everything or already knew to watch for this issue. I don't know if that's been fixed or not. The very fact that this could stand for so long, and how implicit the whole thing was about something so fundamental (object construction!), really bothered me about Scala though.

paulddraper 10y ago
You can have local variables in the constructor. The discussion you linked to shows you how.
- sixbrx 10y ago
  Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned). If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pretty bad, I'd rather just do factories.
  - paulddraper 10y ago
    class Rational(n: Int, d: Int) { require(d != 0) val (numer, denom) = { val g = gcd(n.abs, d.abs) (n / g, d / g) } // ... private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b) } Now `g` is a local variable.
    - sixbrx 10y ago
      As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009: $ scalac -version Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc. $ javap -private Rational Compiled from "Rational.scala" public class Rational { private final scala.Tuple2 x$1; private final int numer; private final int denom; public int numer(); public int denom(); private int gcd(int, int); public Rational(int, int); }
      - paulddraper 10y ago
        Sure, okay. But the point remains that "you couldn't have local/temporary variables in your class constructors" isn't quite true. FYI, you could avoid that but not without giving up `final`. This isn't exactly unusual. Lots of source languages (e.g., C) don't expose all the abilities of the target language (ASM). I'm surprised you mention this shortcoming compared to Java. I would have mentioned the lack of a Java enumeration equivalent.

by sixbrx 10y ago

paulddraper 10y ago

You can have local variables in the constructor. The discussion you linked to shows you how.

sixbrx 10y ago
Which post # in the discussion did you have in mind? There's some misdirections in that thread with ideas that didn't survive the javap test (which I think rather makes my point). I may do Scala again in the future and would like to know how to avoid this (without factory methods as I mentioned). If you mean Paul P/extempore's self described "if you can handle a little perversion" method then - "no thanks", that's pretty bad, I'd rather just do factories.
- paulddraper 10y ago
  class Rational(n: Int, d: Int) { require(d != 0) val (numer, denom) = { val g = gcd(n.abs, d.abs) (n / g, d / g) } // ... private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b) } Now `g` is a local variable.
  - sixbrx 10y ago
    As discussed in the thread, that doesn't work given that we're trying to avoid extra storage, it adds an extra tuple member to the class. It's still true as of the latest compiler just like it was in 2009: $ scalac -version Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc. $ javap -private Rational Compiled from "Rational.scala" public class Rational { private final scala.Tuple2 x$1; private final int numer; private final int denom; public int numer(); public int denom(); private int gcd(int, int); public Rational(int, int); }
    - paulddraper 10y ago
      Sure, okay. But the point remains that "you couldn't have local/temporary variables in your class constructors" isn't quite true. FYI, you could avoid that but not without giving up `final`. This isn't exactly unusual. Lots of source languages (e.g., C) don't expose all the abilities of the target language (ASM). I'm surprised you mention this shortcoming compared to Java. I would have mentioned the lack of a Java enumeration equivalent.