lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx's image size reduction


From: Klaus Weide
Subject: Re: lynx-dev lynx's image size reduction
Date: Mon, 15 Mar 1999 09:24:41 -0600 (CST)

On Mon, 15 Mar 1999 address@hidden wrote:
[Vlad Harchev:]
> >   Here is a recipe how the lynx image size can be reduced: 
> >   Several arrays can be substituted with pointers, which should be 
> > initialized by malloc at initialization. Here are sizes of arrays that can 
> > be eliminated this way ( for lynx-2.8.2dev19 compiled by GCC 2.7.2.3 on  
> > i386-linux-gnu without lss support, no options to 'configure' ) 
> >   LYMain.c: sizeof(links) = 49152
> >   LYMain.c: sizeof(history) = 40960 

There was a patch for dynamically allocating links a long long time ago
(probably around or before 2.6) - it never got integrated, instead the
default size of links[] in userdefs.h was increased.

You can either allocate the memory for these in one chunk - then there's
no runtime benefit since they are always needed [ well, maybe not if
one uses just -source or something like that, or if one views just one
text/plain file and then quits - probably not worth optimizing for this ],
it's just "cheating" because the memory doesn't show up in 'size' etc.
Or one could allocate parts of the arrays in chunks on demand, which
requires extra logic, likely introduces bugs initially (does anyone want
to do it?).

> >  Ie ~90K can be eliminated. Moreover, compiling with lss support, adds the 
> >  following arrays to the mentioned above: 
> >   LYStyle.c: sizeof(hashStyles)=196632 
> >   GridText.c: sizeof(cached_styles)=32768 
> >  
> >  This means that 319512 bytes can be eliminated from  lynx compiled with 
> >  lss support. Frankly speaking, cached_styles in GridText.c is a 2d array, 
> >  so the trick that is applicable to 1d arrays won't work, but it's only 
> >  32K.

Due to its nature hashStyle is an all-or-nothing thing, it doesn't make sense
to allocate only parts of it.  Unless the whole color style hashing method
is revised.  (It doesn't deal with hash collisions, the code just hopes there
won't be any - which is more likely true if the table is much bigger than
would be needed.  This deserves fixing, but more fundamental than just
allocating everything dynamically.)

Anyway, people for whom small runtime memory is an important requirement
definitely shouldn't use color styles.

> not really. those arrays are still allocated (and uninitialized data don't
> make the executable file larger).

So I agree.

> allocating the arrays is ok for other reasons (making the program more
> configurable).


  Klaus

reply via email to

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