Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11

[Bela Lubkin]

I wrote:

> Thomas Dickey wrote:
> 
> > 2002-11-11 (2.8.5dev.10)
> 
> > * modify GridText.c to store lines, anchors, and forms in the same HText 
> > memory
> >   pool as styles.  This will optimize memory allocation/deallocation by 8Kb
> >   units.  The down side:  lines in TRST mode will be stored twice.  Some
> >   structs are made a bit more compact -LP

BTW, regarding the effectiveness of this (or Leonid's other efficiency
changes)...

I tested on the pages:

  http://www.armory.com/cache/userinfo.html
  http://www.armory.com/cache/userinfo-t.html

which are two different versions of 450 lines of data with multiple
links per line.  I tested rendering speed on the basic data files, then
on versions where I had duplicated the 450 data lines an additional 7 or
15 times (8 or 16 total copies, 3600 or 7200 total lines).  I compared
performance of an old Lynx 2.8.4dev.20 binary vs. today's 2.8.5dev.11.
I also compared output, verifying that they were in fact identical.

The results show that Leonid grossly underestimated the benefits of his
changes:

   File                   2.8.4dev.20     2.8.5dev.11
                                -dump            -dump
                         -dump  -nolist   -dump  -nolist
  userinfo450.html        0.10   0.08      0.08   0.06
  userinfo450-t.html      0.10   0.11      0.09   0.10
  userinfo3600.html       4.95   2.50      0.48   0.42
  userinfo3600-t.html     5.30   4.56      0.54   2.50
  userinfo7200.html      28.24  10.54      0.93   0.83
  userinfo7200-t.html    27.93  20.25      1.08  10.29

(CPU-seconds on 1GHz Pentium III)

Leonid's changes make performance (on this data set) linear in the
number of lines, vs. some sort of quadratic behavior.  30 times as fast,
in the worst case here.  Bravo.

Oddly, `lynx -dump -nolist` is now slower than `lynx -dump` in some
cases...

>Bela<

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