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 systems. 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 color Leonid> styles. So it is an inherited code, I just clean it a bit and left as is. 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 HText_BeginAnchor(), Leonid> e.g. once a line or anchor (and we have *functions* HText_getLastChar() and Leonid> HText_AppendCharacter() called for each character). It also used in ~5 other Leonid> places in GridText.c which called very seldom. I think the code growth is Leonid> not that dramatic comparing to lynx in general:) Leonid> ALLOC_IN_POOL may be rewritten as function but not before Tom will release 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". >Bela< ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to [EMAIL PROTECTED]
