mirror of
git://git.sv.gnu.org/emacs.git
synced 2026-03-26 08:41:47 -07:00
Avoid loose big-o usage.
Copied from Perforce Change: 183454 ServerID: perforce.ravenbrook.com
This commit is contained in:
parent
c40a1e173e
commit
aa4deca229
2 changed files with 5 additions and 4 deletions
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue