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

[Bela Lubkin]

Leonid Pauzner wrote:

> Three patches aginst GridText.c attached
> (please check whether uuencoded patches now applyed cleanly).

All apply cleanly!

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

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

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

Now the interesting factors are things like: is this code hot in the CPU
cache?  If it's a function, only one copy has to be hot in the cache, so
your cache footprint is smaller.  Your code is less likely to be pushed
out by something else; something else is less likely to be pushed out by
you.  At about the same level: does the CPU's branch prediction table
remember how the decisions went last time through this code?  Not if
you've scattered copies of the same code all over the place -- it has
no clue that they're from the same source, have the same basic behavior
patterns.

Next level up: are the virtual address translations for the pages that
contain your code (one copy as a function, or many as a macro) in the
CPU's TLB?

Are the pages themselves in core or do they have to be paged in from the
executable image?  How big is the image itself?  Will paging these pages
in cause some of your own data pages to be swapped out; will you get in
a fight with some other process, trading control of certain physical
memory pages back and forth?

Macros that contain significant amounts of code thwart many levels of
hardware optimization.

>Bela<

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