summaryrefslogtreecommitdiffstats
path: root/src/tools/clippy/src/docs/linkedlist.txt
blob: 986ff1369e3c150f5a7d838a4f81922d920af44d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
### What it does
Checks for usage of any `LinkedList`, suggesting to use a
`Vec` or a `VecDeque` (formerly called `RingBuf`).

### Why is this bad?
Gankro says:

> The TL;DR of `LinkedList` is that it's built on a massive amount of
pointers and indirection.
> It wastes memory, it has terrible cache locality, and is all-around slow.
`RingBuf`, while
> "only" amortized for push/pop, should be faster in the general case for
almost every possible
> workload, and isn't even amortized at all if you can predict the capacity
you need.
>
> `LinkedList`s are only really good if you're doing a lot of merging or
splitting of lists.
> This is because they can just mangle some pointers instead of actually
copying the data. Even
> if you're doing a lot of insertion in the middle of the list, `RingBuf`
can still be better
> because of how expensive it is to seek to the middle of a `LinkedList`.

### Known problems
False positives – the instances where using a
`LinkedList` makes sense are few and far between, but they can still happen.

### Example
```
let x: LinkedList<usize> = LinkedList::new();
```