about summary refs log tree commit diff
path: root/src/docs/linkedlist.txt
diff options
context:
space:
mode:
Diffstat (limited to 'src/docs/linkedlist.txt')
-rw-r--r--src/docs/linkedlist.txt32
1 files changed, 0 insertions, 32 deletions
diff --git a/src/docs/linkedlist.txt b/src/docs/linkedlist.txt
deleted file mode 100644
index 986ff1369e3..00000000000
--- a/src/docs/linkedlist.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-### 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();
-```
\ No newline at end of file