[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH] to dev13 - various fixes
From: |
Leonid Pauzner |
Subject: |
Re: lynx-dev [PATCH] to dev13 - various fixes |
Date: |
Thu, 4 Nov 1999 13:53:20 +0300 (MSK) |
31-Oct-99 18:04 Vlad Harchev wrote:
> * Added comments about pools.
> --- lynx2-8-3dev13u-was/src/GridText.c Fri Oct 29 18:26:35 1999
> +++ lynx2-8-3dev13u/src/GridText.c Sun Oct 31 15:24:34 1999
> +same members as HTStyleChangePool). Pools are used for allocation of groups
> +of objects of the same type T. Pools are represented as a list of structures
> +of type P (called pool chunks here). Structure P has an array of N objects of
> +type T named 'data' (the number N in the array can be chosen arbitrary),
> +pointer to the next pool chunk named 'pool', and the number of free items
> +in that pool chunk named 'free_items'. Ie, here is a definition of the
> +structure P:
> + struct P
> + {
> + T data[N];
> + struct P* next;
> + int free_items;
> + };
> + It's recommened that sizeof(P) be memory page size minus 32 in order
> malloced
> +chunks to fit in machine page size.
> + Allocation of 'n' items in the pool is implemented as decrementing member
> +'free_items' by 'n' if 'free_items' >= 'n', or allocating a new pool chunk
> and
> +allocating 'n' items in that new chunk. It's task of programmer to assert
> that
> +'n' is <= N. Only entire pool may be freed - this limitation makes allocation
> +algorithms trivial and fast - so the use of pools is limited to objects that
> +are freed in batch, that are not deallocated not in the batch, and not
> +reallocated.
There is probably an exception in lynx internals:
TEXTAREA editing code make a surgery on HText object
which was previously allocated.
Have no idea about color styles but seems that part of code
may be affected by textarea growth.
(my $0.02).
> + Pools greatly reduce memory fragmentation and memory allocation/deallocation
> +speed due to the simple algorithms used. Due to the fact that memory is
> +'allocated' in array, aligment overhead is minimal. Allocating strings in a
> +pool provided thier length will never exceed N and is much smaller than N
> +seems to be very efficient.
> +
> + Pool are referenced by pointer to the chunk that contains free slots. Macros
> +that allocate memory in pools update that pointer if needed.
> + There are 3 macros that deal with pools - POOL_NEW, POOL_FREE and
> +ALLOC_IN_POOL.
> + Here is a description of those macros as C++ functionts (with names
> mentioned
> +above and with use of C++ references)
> +
> +void ALLOC_IN_POOL( P*& pool, pool_type, int toalloc, T*& ptr)
> + - allocates 'toalloc' items in the pool of type 'pool_type' pointed by
> + 'pool', sets the pointer 'ptr' to the "allocated" memory and updates
> 'pool'
> + if necessary. Sets 'ptr' to NULL if fails.
> +
> +void POOL_NEW( pool_type , P*& ptr)
> + Initializes a pool of type 'pool_type' pointed by 'ptr', updating 'ptr'.
> + Sets 'ptr' to NULL if fails.
> +
> +void POOL_FREE( pool_type , P* ptr)
> + Frees a pool of type 'pool_type' pointed by ptr.
> +
> + - VH */
- Re: lynx-dev [PATCH] to dev13 - various fixes,
Leonid Pauzner <=