0

I plan to populate an immutable HashMap inside a scala class instance using a builder, then expose the hashMap with a method calling result() on the builder.

Is this call very cheap or is it worth saving this result in a member field for faster access? The operations that run after each call are on the order of a couple (say 5) calls to the exponential function.

michael meyer
  • 169
  • 2
  • 9
  • 2
    I think you may want to rephrase your question in a clearer way, I find it pretty hard to understand what you are asking. 1) When you say "inside an object", do you mean a Scala object or an instance of something? 2) are you going to recompute the hashmap on every result() call or just on the first one laziness? 3) I have no idea what you mean by "he operations that run after each call are on the order of a couple (say 5) calls to the exponential function.", nor how it's relevant. – Diego Martinoia Nov 05 '14 at 16:05
  • @Diego The calls to result will take place after the HashMap is in its final state. If the operations that run after each call to result() are much more expensive than the call itself, then the call to result() does not matter. – michael meyer Nov 05 '14 at 16:38
  • See my answer below and let me know if I understood your problem correctly. – Diego Martinoia Nov 05 '14 at 16:52

1 Answers1

0

While it's true that, if the usage of result is much more expensive than the computation of result, then the call to result is negligible, since you are using an immutable result there is no point in recomputing it every time.

Anyways, looking at the source code here the call to result seems pretty optimized. Nonetheless, I don't see why you wouldn't want to save the result somewhere: albeit a little improvement, it's kind of free to do :)

Diego Martinoia
  • 4,592
  • 1
  • 17
  • 36
  • I think there is a misunderstanding: I am using a builder provided by the scala collection library to grow the immutable HashMap. When I insert elements into this builder I assume that some recomputation takes place immediately so that in principle the call to result() thereafter could be negligible. The HashMap is not being recomputed it is merely read from. – michael meyer Nov 05 '14 at 17:42
  • Can you post all the relevant code in your question? – Diego Martinoia Nov 06 '14 at 10:07
  • The intended use is as follows: `import scala.collection.immutable.VectorBuilder class HasVector { private val vb = Vector.newBuilder[Double] def add(d:Double) = vb+=d def getVector = vb.result() }` First all the elements are added, thereafter the calls to result are made. – michael meyer Nov 07 '14 at 09:20
  • It's not even a Map, it's a Vector >.< Please try to be more precise next time. Anyways, looking at the source code here (https://github.com/scala/scala/blob/5e0880fe05fb65a8757721be7e5be6a3259c19a8/src/library/scala/collection/immutable/Vector.scala ) the call to result seems pretty optimized. Nonetheless, I don't see why you wouldn't want to save the result somewhere: albeit a little improvement, it's kind of free to do :) – Diego Martinoia Nov 07 '14 at 09:39
  • 1
    If you copy your comment into your answer I will happily accept it. Sorry about the imprecision, there is no working code yet, I thought it is enough to illustrate what will be going on in principle. – michael meyer Nov 07 '14 at 10:34
  • For readers wondering: in the source code linked to in the answer we see that the method result returns a copy. This is unexpected since this is expensive. – michael meyer Nov 07 '14 at 13:24
  • To be fair, it is kind of expected: no one prevents you from calling other Add's in between different result calls. That's your personal code not doing it, but the library builder has to offer this functionality :) – Diego Martinoia Nov 07 '14 at 14:22