Re: NotParticularlyFastArrayBuffer

On 2008-09-01 10:12:28 David MacIver wrote:
> So, it might have been true at one point that it was faster than the
> scala standard ArrayBuffer, but if that's the case then apparently
> it's been fixed. Here are some benchmarks (which are checked into the
> repository now, so you can run them yourself). (Nominally numbers are
> milliseconds, but the low size numbers should be regarded as pretty
> untrustworthy and I wouldn't really trust these as an absolute metric
> due to overhead. They seem to be pretty good relative metrics though)

Yes, the optimisation that FastArrayBuffer makes was moved into Scala
by Stepan, sometime around 2.7.0.

> These aren't intended to benchmark any specific feature (the first
> measures both applies and updates, the second iteration and appends),
> just to give a general idea of the speed of FastArrayBuffer. And as
> you can see from the numbers there's not really a lot in it between it
> and ArrayBuffer. Consequently, FastArrayBuffer should probably be
> deprecated.

Possibly, though I have some more ideas to make it faster.

Believe me you will find worse cruft than that in the repo at the
moment. This why I've been reluctant to make a big release.

> In general, when creating classes to work around deficiencies in
> standard library implementations they should probably go in some
> central place for such classes and share the name of the class they
> replace.

Disagree. FastArrayBuffer and ArrayBuffer may do the same thing, but
they are not interchangeable because, well, they aren't the same class.
Giving them the same name would just be confusing.
(java.{util,sql}.Date really pisses me off.)

> That way when the bugs in the standard library that made them
> necessary are fixed it becomes a bit easier to deprecate them and for
> users to replace them with the "real" versions.

To me that's a pretty small difference compared to the disadvantage in
readability.

/J