lynx-dev
[Top][All Lists]
Advanced

[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 */




reply via email to

[Prev in Thread] Current Thread [Next in Thread]