
Fast immutable vectors in C# - luu
http://julesjacobs.github.io/2014/11/11/immutable-vectors-csharp.html
======
0xffff2
Fast immutable collections are easy when your collections aren't actually
immutable.
[http://www.reddit.com/r/programming/comments/2lyf8f/fast_imm...](http://www.reddit.com/r/programming/comments/2lyf8f/fast_immutable_vectors_in_c_10x_faster_and_90/clzloli)

~~~
corysama
Fix commited:
[http://www.reddit.com/r/programming/comments/2lyf8f/fast_imm...](http://www.reddit.com/r/programming/comments/2lyf8f/fast_immutable_vectors_in_c_10x_faster_and_90/clzpuwv)

------
Bognar
Comparisons with ImmutableList<T> from Microsoft aren't necessarily valid,
since ImmutableList<T> supports insertion and removal at arbitrary points. The
implementation in the article is optimized for adding at the end.

~~~
DenisM
That's why there are two separate methods on this class - Add (at the end) and
Set (anywhere). Both outperform the corresponding ImmutableList<T>, according
to the article.

~~~
danbruc
But Set can just overwrites the specified element while Insert will insert the
element at the specified position by pushing the element and all following
elements out of the way.

~~~
SideburnsOfDoom
> But Set can just overwrites the specified element

Kind of: Set returns a new Vector with a changed state (the specified element
overwritten).

But yes, this implement is very sparse: there's no way to add and remove
elements in the middle, no way to even tell how many elements are in the list:
[https://news.ycombinator.com/item?id=8592178](https://news.ycombinator.com/item?id=8592178)

Perhaps omitting them hides some different optimisation choices (i.e. they
would be more expensive)

Maybe it's just a proof of concept?

------
SideburnsOfDoom
Hm.. am I missing something? there's no Count property on the Vector
interface.

If Lookup and Set take an index (int i), and you can't tell how many items
there are in the vector, what happens when you specify an index way past the
end to one of those?

~~~
alkonaut
That is really odd (unless I'm also missing something). It should be trivial
to implement a count.

~~~
SideburnsOfDoom
It should be trivial. The only reasonable explanation that I can think of is
that it was't needed for a Proof of Concept.

------
_random_
_" If there’s interest in a full featured production quality version, I may
implement that."_

That would be great.

------
joosters
But... this isn't actually a vector. It stands to reason that if you use a
different data structure then you will get different timing properties, but
you are not comparing like-for-like.

~~~
alkonaut
What is a vector? There is nothing that says a vector has to be a sequentially
stored array. If you agree that the interface is a vector interface, then it
"is" a vector.

~~~
joosters
That's pretty much the definition of it. It's what just about every language
out there calls a vector.

If you want a blackbox object that has Lookup(), Add() and Set() but with no
guarantees about the underlying algorithm, you should probably avoid calling
it a vector...

~~~
SideburnsOfDoom
> If you want a blackbox object that has Lookup(), Add() and Set() but with no
> guarantees about the underlying algorithm, you should probably avoid calling
> it a vector.

"Vector" here is an _interface_.

The equivalent, e.g. "interface ILinkedListVector" is considered bad practice,
i.e. you do want an interface to be a back box and not leak implementation
details. if it has the right operations, "Vector" (actually more like
"IVector<T>") is an acceptable interface name.

------
Ono-Sendai
I have something similar in C++, works pretty well.

