PrismitaLEARN · PRACTICE · GROW

When would you use a LinkedList instead of a List?

C# Collections Intermediate 2–3 Yrs3–5 Yrs Conceptual 1 min read

Quick Answer

Almost never in practice. A LinkedList<T> gives O(1) insert/remove if you already hold the node, but it has no index access (O(n) to find a position), poor cache locality (nodes scattered in memory), and per-node allocation overhead. A List<T>'s array is faster for almost all real workloads despite O(n) middle inserts.

Honestly, almost never. The textbook says LinkedList is O(1) for insertion in the middle versus O(n) for a List, but that's only true if you already have a reference to the node — and normally you have to walk the list to find the spot, which is O(n) anyway. Meanwhile a List is a contiguous array, so iterating it is way faster because of CPU cache locality, and it doesn't allocate a node object per element. The one place LinkedList genuinely pays off is something like an LRU cache where you keep node references and splice them to the front.

  • The theoretical LinkedList advantage rarely materialises because you usually have to search for the insertion point first, which is O(n).
  • CPU cache effects mean iterating a contiguous List is often 10×+ faster than a LinkedList.
  • For a queue/stack use Queue<T>/Stack<T>; for a deque, System.Collections.Generic now has no built-in — often a List or a ring buffer is best.
  • Legit LinkedList use: an LRU cache where you hold node references and move them to the front in O(1).
All C# questions More on Collections