From 1915e6feb474aa54edeb54668bb316fd711b3864 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Tue, 14 Jan 2020 11:48:09 +0100 Subject: [PATCH] Minor improvements to linked list section --- .../second-edition/posts/11-allocator-designs/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/blog/content/second-edition/posts/11-allocator-designs/index.md b/blog/content/second-edition/posts/11-allocator-designs/index.md index 5c301b3a..3ab8dcfc 100644 --- a/blog/content/second-edition/posts/11-allocator-designs/index.md +++ b/blog/content/second-edition/posts/11-allocator-designs/index.md @@ -784,9 +784,9 @@ The `linked_list_allocator` crate implements this merging strategy in the follow As we learned above, the bump allocator is extremely fast and can be optimized to just a few assembly operations. The linked list allocator performs much worse in this category. The problem is that an allocation request might need to traverse the complete linked list until it finds a suitable block. -Since the list length depends on the number of unused memory blocks, the performance can vary extremely for different programs. A program that only creates a couple of allocations will experience a relatively fast allocation performance. For a program that fragments the heap with many allocations, however, will experience a very bad allocation performance. +Since the list length depends on the number of unused memory blocks, the performance can vary extremely for different programs. A program that only creates a couple of allocations will experience a relatively fast allocation performance. For a program that fragments the heap with many allocations, however, will experience a very bad allocation performance because the linked list will be very long and mostly contain very small blocks. -It's worth noting that this performance issue isn't a problem with our implementation, but a fundamental disadvantage of the linked list approach. Since allocation performance can be very important for kernel-level code, we explore a third allocator design in the following that trades improved performance for reduced memory effiency. +It's worth noting that this performance issue isn't a problem with our implementation, but a fundamental disadvantage of the linked list approach. Since allocation performance can be very important for kernel-level code, we explore a third allocator design in the following that trades improved performance for reduced memory utilization. ## Fixed-Size Block Allocator