From aa4deca229b60c9950674c1c41b7b0a8cceda532 Mon Sep 17 00:00:00 2001 From: Gareth Rees Date: Tue, 17 Sep 2013 11:58:32 +0100 Subject: [PATCH] Avoid loose big-o usage. Copied from Perforce Change: 183454 ServerID: perforce.ravenbrook.com --- mps/design/cbs.txt | 6 +++--- mps/design/freelist.txt | 3 ++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/mps/design/cbs.txt b/mps/design/cbs.txt index 226f971d56c..d130f3728de 100644 --- a/mps/design/cbs.txt +++ b/mps/design/cbs.txt @@ -251,9 +251,9 @@ if there is no suitable block. _`.impl.find-largest`: ``CBSFindLargest()`` simply finds out the size of the largest block in the CBS from the root of the tree, using ``SplayRoot()``, and does ``SplayFindFirst()`` for a block of that -size. This is O(log *n*) in the size of the free list, so it's about -the best you can do without maintaining a separate priority queue, -just to do ``CBSFindLargest()``. +size. This takes time proportional to the logarithm of the size of the +free list, so it's about the best you can do without maintaining a +separate priority queue, just to do ``CBSFindLargest()``. Low memory behaviour diff --git a/mps/design/freelist.txt b/mps/design/freelist.txt index c8e817edaea..a9c329e1ff3 100644 --- a/mps/design/freelist.txt +++ b/mps/design/freelist.txt @@ -29,7 +29,8 @@ situations, when memory is not available for the control structures needed by other allocators. In these situations the free list allocator ensures that memory is not lost, but with several disadvantages: -1. operations on the free list are O(n) in the number of free blocks; +1. operations on the free list take time proportional to the number of + free blocks; 2. the data structures are stored in client memory and so are vulnerable to corruption; 3. the data structures have poor locality (and thus potentially poor