[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev 2.8.5dev.11 using too much RAM

From: Bela Lubkin
Subject: Re: lynx-dev 2.8.5dev.11 using too much RAM
Date: Wed, 18 Dec 2002 14:40:24 -0800

Leonid Pauzner wrote:

Leonid>>> patch #1: bela.dif
Leonid>>> changes proposed by Bela Lubkin, to optimize ALLOC_IN_POOL macro
Leonid>>> substitution, pack bitfields in HTStyleChanges more compact on some 
Leonid>>> Applied against clean dev.11 in either way.

Bela>> This is the only one of the three patches that I've actually attempted
Bela>> to analyze.  It's true that it implements some suggestions of mine, but
Bela>> not the main one, which was that I still think that ALLOC_IN_POOL should
Bela>> be a function, not a macro.  It's a lot of code to be duplicating.  It
Bela>> would require a little work to preserve the type polymorphism, but not
Bela>> much (as long as you're willing to restrict the polymorphism to the
Bela>> types you already intend to use it with).

Bela>> Large macros are generally performance-negative.  Once upon a time
Bela>> it may have been a win to avoid the overhead of establishing a call
Bela>> frame, doing a call and return, etc.  Those times are gone.

Leonid> Bela, I completely agree with you. I want to say only the following:

Leonid> - ALLOC_IN_POOL appears as macros in 1999 when it was implemented for 
Leonid> styles. So it is an inherited code, I just clean it a bit and left as 

Leonid> - The pool-allocation code, of cause, significantly faster than malloc,
Leonid> but it is not a hot point: it is used in split_line() and 
Leonid> e.g. once a line or anchor (and we have *functions* HText_getLastChar() 
Leonid> HText_AppendCharacter() called for each character). It also used in ~5 
Leonid> places in GridText.c which called very seldom. I think the code growth 
Leonid> not that dramatic comparing to lynx in general:)
Leonid> ALLOC_IN_POOL may be rewritten as function but not before Tom will 
Leonid> dev version that work (no leaks nor memory overrun).

Ok, no problem.  I hadn't looked backwards at the pre-dev11 version of
the code, to see that the ALLOC_IN_POOL macro was old.  I was actually
guessing you had picked it up from some other package where maybe it was
used for more diverse types.  (Maybe the color style code picked it up
from such an external source.)  (but a google search for "ALLOC_IN_POOL"
only matches Lynx and a function in the Linux kernel.)

I'm not complaining, just wanted the record to show that when you said
"changes proposed by" you did not mean "complete satisfaction of changes
proposed by".


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

reply via email to

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