Re: lynx-dev Possible Bug in Lynx 2.8.5-dev.15

[Ilya Zakharevich]

Thomas Dickey wrote:

    what it appears to do is alter a place where a realloc would shrink,
    to caching it in a pool under the assumption that the chunk would not be
    increased at a later point in the code.  But it wasn't clear why the
    alternative (defined-out chunk) used a lot more memory.

If it is still not clear:

 with the taken branch: 

   lynx does not free() memory (until very late), and never realloc()s.

   The memory allocation strategy is: allocate in big chunks; free()
   them all in one sweep.

 with the commented out branch:

   lynx malloc()s interspersed with realloc().  It also uses small
   malloc()s (and realloc()s).

With the second strategy (textually it is earlier in the C file ;-) we
are in the mercy of the implementation of malloc().  Sometimes it
could fullfill our requests effectively; sometimes it will spend a lot
of time trying to fit all the fragments into the "holes"; sometimes it
will spend a lot of time, and will not find appropriate holes.

The first strategy takes more work to implement, but effectively we do
not depend on malloc() cleverness at all.

Hope this helps,
Ilya

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden