« Return to Thread: NotParticularlyFastArrayBuffer
Re: NotParticularlyFastArrayBuffer
by David MacIver
::
Rate this Message:
On Mon, Sep 1, 2008 at 8:50 PM, Jamie Webb <j@...> wrote:
> 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.
Looks like it didn't make it into 2.7.1 actually. Or at least 2.7.1
was still suffering from the overly polymorphic array problem, even if
it had other issues fixed.
>> 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.)
Conveniently, things don't live in a global namespace. Particularly in
Scala where you have hierarchical packages and imports and renaming of
imports. The painfullness of doing such things in Java shouldn't
prevent us from doing hem in Scala.
>> 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.
I don't find it's a significant disadvantage in readability. When I
need to distinguish between them I use one or both partially qualified
(e.g. Map, immutable.Map and mutable.Map).
> 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.
Looks like it didn't make it into 2.7.1 actually. Or at least 2.7.1
was still suffering from the overly polymorphic array problem, even if
it had other issues fixed.
>> 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.)
Conveniently, things don't live in a global namespace. Particularly in
Scala where you have hierarchical packages and imports and renaming of
imports. The painfullness of doing such things in Java shouldn't
prevent us from doing hem in Scala.
>> 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.
I don't find it's a significant disadvantage in readability. When I
need to distinguish between them I use one or both partially qualified
(e.g. Map, immutable.Map and mutable.Map).
« Return to Thread: NotParticularlyFastArrayBuffer
| Free embeddable forum powered by Nabble | Forum Help |
