The title is mostly self-explanatory: what are the advantages of linked lists over binary trees? The only case I can think of in which a linked list is more efficient is for iterating over every element, in which case it's still pretty close. It looks like binary trees are faster at both accessing data and inserting new elements. So why use a linked list at all?
+1
A:
A linked list is not generally used as an associative container (READ: Not to be used as a dictionary) -- only as a literal list of items, like an array. Binary trees' performance when such a simple data structure is desired is poor.
Billy ONeal
2010-01-10 05:48:10
+3
A:
It's easier/faster to delete items from a linked list compared to a binary tree which could require few operations to fix the tree.
tomzx
2010-01-10 05:59:05
+5
A:
If the tail of a linked list is stored, then insertion into a linked list is decidedly faster than insertion into a binary tree. Insertion into a binary tree is O(N) at worst case (O(log N) at best) if it's unbalanced. If it's balanced, then insertions are O(log N), but there is house keeping involved in keeping it balanced. Insertion into a linked list is O(1) if the tail is kept.
Also, as BillyONeal mentioned, a binary tree is usually an associative structure, whereas linked lists are not.
P Daddy
2010-01-10 06:00:40
That's true for a binary *search* tree, but in the more general case of an (unsorted) binary tree, insertions are still O(1) -- a linked list is, after all, just a degenerate binary tree.
Ken
2010-01-10 06:12:52
@Ken: A tree is useless if *some* concept of sort isn't applied. This may not be a lexical order, perhaps, but some index. In any case, a path must be followed to find the correct node at which to add a new value, which still means O(log N) at best and O(N) at worst. An O(1) insertion can only apply if the node to which an item is added is unimportant, but in this case, lookups are O(N), and there is no organization to the data at all, so the overhead of a tree comes with no benefit.
P Daddy
2010-01-10 06:26:14
@P Daddy, Insertion is a confusing term when talking about linked lists. Append is the O(1) operation, insertion is O(n).
Ash
2010-01-10 06:30:40
@Ash: You are right, but I purposefully chose to not muddy the issue with this detail. I'm assuming unordered data (which I suppose may be a poor assumption). Certainly for data which must be ordered, a linked list would be a poor choice to even consider, let alone spark this question.
P Daddy
2010-01-10 06:42:07
P Daddy: My compiler here builds an AST. That's a tree which is not sorted by any key, yet still very useful. :-)
Ken
2010-01-10 07:06:26
It is indeed ordered. The order of operations determines its structure, as do decision points. An item must be added at the correct place in order for correct execution. Granted, though, a presumption of "add the next item to the same node as the previous item, unless *{some condition}* " could reduce some inserts to O(1), but this is very, ahem, abstract.
P Daddy
2010-01-10 07:17:10
Ordered != sorted
Ken
2010-01-10 17:23:39
Since the definition of "to sort" is "to place in order", I'd argue that yeah, it is, but it's a meaningless semantic argument. The point is that, given a ground state, a tree must be traversed to find the appropriate place at which to add a new item. It must have some concept of "follow this path to get to this node". This is the sole benefit of trees and their entire raison d'être. A tree with no concept of order is meaningless.
P Daddy
2010-01-10 20:53:22
+2
A:
In linked list the objects are ordered by the container itself, so you don't need to have a comparison function for the objects.
antti.huima
2010-01-10 06:02:11
A:
A fair question. I like to use the container that most "tightly" fits my needs. For example, you can use a list when all you need is a queue with no real consequence either... but... queues are highly optimized for this one specific task of popping off the front, and inserting at the back, with no extra pointers, or anything. By using the most appropriate class, you can be sure you're not getting any extra fluff, even if it has the same Big-O. Sometimes those hidden constants do matter.
Mark
2010-01-10 06:08:04
A:
It mostly depends on scenario. If tail of linked list is maintained then insertion is fast in linked list. Deletion is quite fast in linked list but in case of searching it is better in trees( o(log(n) for height balance tree ) while o(n) in linked list.
GG
2010-01-10 06:17:18
A:
I assume you're talking about actual binary search trees where the nodes are added using algorithms to maximize retrieval performance. As opposed to a simple tree where each node has a maximum of 2 child nodes.
A linked list is often unsorted and so addition of new nodes is simply an O(1) operation normally by appending to the tail of the list.
On the other hand a binary tree must store nodes in a specific ordering mechanism (and possibly enforce balancing) to provide for a more efficient searching/retrieval operation.
If your algorithm does NOT need to retrieve items very efficiently while also provide efficient sorting of the items, a linked list is probably all you need.
Queues and Stacks are examples of data structures that can be happily implemented using a linked list.
Note: Insertion to a linked list is a different (slower) operation than basic addition/append. Insertion often requires traversal along the list until the correct position is found, O(n) where n is the list length. An append is simply adding to the tail of the list (hence O(1))
Ash
2010-01-10 06:27:34