[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11
From: |
Leonid Pauzner |
Subject: |
Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11 |
Date: |
Mon, 2 Dec 2002 13:44:50 +0300 (MSK) |
2-Dec-2002 00:24 Bela Lubkin wrote:
> 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)...
The above changes gives no visible speedup except HText_free()
which became *significantly* faster, by factor >100.
The quadratic vs linear complexity changes shows roughly 2 times improvement
on my test file I wrote about. Numbers of persents were from gprof flat
profile, just a guidline.
> 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.
Thanks to gprof...
> Oddly, `lynx -dump -nolist` is now slower than `lynx -dump` in some
> cases...
>>Bela<
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
- lynx-dev lynx2.8.5dev.11, Thomas Dickey, 2002/12/01
- ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Bela Lubkin, 2002/12/02
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Bela Lubkin, 2002/12/02
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11,
Leonid Pauzner <=
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Leonid Pauzner, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Bela Lubkin, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Thomas Dickey, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Clemens Fischer, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Thomas Dickey, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Bela Lubkin, 2002/12/04
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Leonid Pauzner, 2002/12/04
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Thomas E. Dickey, 2002/12/04
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Leonid Pauzner, 2002/12/03
- Re: ALLOC_IN_POOL, Re: lynx-dev lynx2.8.5dev.11, Bela Lubkin, 2002/12/04