Arraybuffer specialization

[Pedro Larroy]

Hi

Are there any plans to specialize arraybuffer to avoid boxing? I have been starting to use arraybuilder for this reason but I wonder if there is some reason that prevents specializing arraybuffer in the standard library.

Related issue:

https://issues.scala-lang.org/plugins/servlet/mobile#issue/SI-4596

Pedro.

[Vlad Ureche]

The main reason Scala collections are not specialized is the bytecode size it would generate (at least a 10x increase of the Scala library size).

Instead of specialization, I would recommend giving miniboxing [1] a try. Several collections have been compiled with miniboxing, such as linked lists [2], vectors [3] [4] and streams [5] with really good results.

If you're interested in giving it a shot, I can code a miniboxing-specialized ArrayBuffer for you.

HTH,
Vlad

[1] scala-miniboxing.org
[2] scala-miniboxing.org/example_linkedlist.html
[3] io.pellucid.com/blog/optimistic-respecialization-attempt-6
[4] github.com/nicolasstucki/scala-rrb-vector/tree/adding-miniboxing
[5] github.com/miniboxing/miniboxing-plugin/issues/146

Pedro.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Oliver Ruebenacker]

     Hello,

  How about offering specialized versions of standard collections as extension libraries? Seems like it should be easy to produce and fulfill a clear need.

     Best, Oliver

--

Oliver Ruebenacker

Solutions Architect at Altisource Labs

Be always grateful, but never satisfied.

[Vlad Ureche]

2015-01-26 14:24 GMT+01:00 Oliver Ruebenacker <cur...@gmail.com>:

  How about offering specialized versions of standard collections as extension libraries? Seems like it should be easy to produce and fulfill a clear need.

Good question! So far, most attempts were exploratory, seeing how well things work and what transformations are necessary.

But now that the miniboxing plugin is quite stable, we should really think about developing collections based on it.

I will start working on this after version 0.4 of the plugin is ready.

Cheers,
Vlad

[Pedro Larroy]

Hi Vlad

This is clear, but specializing only ArrayBuffer might not be so much of a size increase wouldn't it? I understand that then the question arises about specializing some collections and not others. Fair enough, but arraybuffer is such a basic data structure that might justify the exception in my opinion.

Thanks.

Pedro.

[Erik Osheim]

On Mon, Jan 26, 2015 at 10:59:13AM +0100, Pedro Larroy wrote:
> Are there any plans to specialize arraybuffer to avoid boxing? I have been
> starting to use arraybuilder for this reason but I wonder if there is some
> reason that prevents specializing arraybuffer in the standard library.

If you're interested, give debox.Buffer[A] a try:

https://github.com/non/debox#buffer

-- Erik

[Pedro Larroy]

Thanks, I did, and I am aware of those projects. The question was more if ArrayBuffer should be specialized in the standard library by default.

Thanks again for the suggestions.

[Vlad Ureche]

2015-01-26 16:43 GMT+01:00 Pedro Larroy <pedro.lar...@gmail.com>:

This is clear, but specializing only ArrayBuffer might not be so much of a size increase wouldn't it? I understand that then the question arises about specializing some collections and not others. Fair enough, but arraybuffer is such a basic data structure that might justify the exception in my opinion.

Pedro, there are many other classes that need to be specialized to fully specialize ArrayBuffer. From scaladoc:

Linear Supertypes:

Serializable, java.io.Serializable, CustomParallelizable[A, ParArray[A]], ResizableArray[A], IndexedSeq[A], collection.IndexedSeq[A], Builder[A, ArrayBuffer[A]], IndexedSeqOptimized[A, ArrayBuffer[A]], collection.IndexedSeqOptimized[A, ArrayBuffer[A]], IndexedSeqLike[A, ArrayBuffer[A]], collection.IndexedSeqLike[A, ArrayBuffer[A]], AbstractBuffer[A], Buffer[A], BufferLike[A, ArrayBuffer[A]], Subtractable[A, ArrayBuffer[A]], Scriptable[A], Shrinkable[A], Growable[A], Clearable, AbstractSeq[A], Seq[A], SeqLike[A, ArrayBuffer[A]], Cloneable[ArrayBuffer[A]], scala.Cloneable, java.lang.Cloneable, Iterable[A], Traversable[A], Mutable, collection.AbstractSeq[A], collection.Seq[A], collection.SeqLike[A, ArrayBuffer[A]], GenSeq[A], GenSeqLike[A, ArrayBuffer[A]], PartialFunction[Int, A], (Int) ⇒ A, collection.AbstractIterable[A], collection.Iterable[A], IterableLike[A, ArrayBuffer[A]], Equals, GenIterable[A], GenIterableLike[A, ArrayBuffer[A]], AbstractTraversable[A], collection.Traversable[A], GenTraversable[A], GenericTraversableTemplate[A, ArrayBuffer], TraversableLike[A, ArrayBuffer[A]], GenTraversableLike[A, ArrayBuffer[A]], Parallelizable[A, ParArray[A]], TraversableOnce[A], GenTraversableOnce[A], FilterMonadic[A, ArrayBuffer[A]], HasNewBuilder[A, ArrayBuffer[A]], AnyRef, Any

In general, specializing a single class in the library doesn't bring any benefit, as most of its methods are implemented in traits. On the contrary, passing values across the specialized/non-specialized boundary kills performance, as it boxes values just to unbox them later, creating mountains of garbage. That's the price you're paying for having all the nice convenience methods uniformly across all collections.

HTH,

Vlad