cody said:
Therefore you should not use InsertAt or IndexOf, instead you should
remember the Nodes where you want to insert so
you don't have to traverse the list every time. Inserting at head or tail
is
cheap as well because theses Nodes are always available.
Inserting at the tail is *adding* and is cheap in all natural collections.
Inserting at the head is probably the most expensive add in an array
however. By directly exposing your underlying nodes, you turn LinkedList
into a more complated and more dificult class. Code using it is going to be
*far* less clear than code using almost any other structure(except perhaps a
non-balanced tree or other such things). It would effectivly remove the most
common known method(Add, Remove, indexer\Item() property) because they don't
make sense when you are effectivly just working over a set of Nodes you need
to work with.
Oddly, maybe 5-8% of my code actually uses inserts and removals to the
extent that a LinkedList *might* have an effect.
Often. Already 40 elements can be a lot when removing and inserting in an
arraylist vs linkedlist.
That may be, but personally I think you're thinking that a LinkedList is a
pancea in all cases, where it is actually a bad idea in most. Either you are
stuck with big performance issues or more complicated code(you start having
to manage the list directly). Outside of extreme performance situations I
would probably argue that using a LinkedList is something to be forbidden in
most situations.
LinkedLists are certainly not useful for int values, but they are for
larger
objects or structs (with generics using structs instead of objects in
LinkedLists can improve performance a lot).
I still doubt it will be a good thing for a large number of structs. For one
thing, a struct shouldn't exceed 16 bytes or so, by using a linked list you
are guarenteeing that the struct *WILL* take up atleast 13 and at most
28bytes while in use. For large amounts of data I would avoid a linked list
like the plauge, instead opting to figure out how to insert it into the
ArrayList structure in the correct order(as always, algorithm beats
structure optimiztions). For classes, you are in the same situation as an
int as the size of a reference is the same as an int32 on 32 bit hardware.
You can't consider the object size when you consider the linked list size
because only the reference matters in either the linked list or the
ArrayList. The number of nodes matters a great deal more than the size of
the node, in reality.
The only problem with LinkedList in .NET is that the whole bunch of
references in a LinkedList slows GC down thats one of the reasons why they
left it out, I suppose.
I suppose it could compliate the GC a bit, but I don't know if thats for
sure or not. The GC has to travel down huge object graphs as it is, while a
linked list is a decent object graph I don't suspect that it will be used in
situations where the graph will be big enough to matter. The memory overhead
really makes it a problem for large numbers of nodes.