[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV How to make Lynx smaller
|
From: |
Klaus Weide |
|
Subject: |
Re: LYNX-DEV How to make Lynx smaller |
|
Date: |
Sun, 26 Oct 1997 20:18:29 -0600 (CST) |
On Mon, 27 Oct 1997, Nelson Henry Eric wrote:
> > Can anyone suggest some strategic locations for #ifdef statements that
> > will let me "trim the fat" from Lynx to create a smaller executable?
> > Also, are there other libraries or compile options that might create a
First you should go through userdefs.h and through the list of compilation
flags to see whether there is something to disable that you don't need.
> Back in Dec. 1996 I did some experimenting on _Un*x_. If you could only
> search the lynx-dev archives, you would find quite a bit on this topic.
> A quote from a post I made Dec. 24, 1996:
>
> Well, not linking in LYUpload.o, LYLocal.o, LYCgi.o, LYDownload.o,
> LYNews.o, LYMail.o, LYJump.o and LYTraversal.o reduces the lynx
> image about 9% (from 663552 to 606208 compiling on sun4 with gcc).
>
> The bottom line is, though, that it would hardly be worth it because
> of the difficulty of _selectively_ removing portions of LYDownload.o
> and LYTraversal.o, which are probably the biggest gainers. These
> two have to be very carefully ifdefed out to prevent introducing bugs.
Here are the last 30 or so lines of the output of
nm -s lynx|sort -n -2 +3
on solaris (2.7.1ac-88 + minor changes compiles with slang). The 3rd
column is size. That might give you an idea what takes up a lot of
space.
[1154] | 286104| 4720|FUNC |GLOB |0 |.text |is_url
[673] | 1168564| 5192|OBJT |LOCL |0 |.bss |tags
[680] | 1136304| 5192|OBJT |LOCL |0 |.data |tags_old
[683] | 1141496| 5192|OBJT |LOCL |0 |.data |tags_new
[1891] | 589252| 5948|FUNC |GLOB |0 |.text |HTLoadFile
[1474] | 132300| 6056|FUNC |GLOB |0 |.text |reply_by_mail
[1922] | 615500| 6216|FUNC |GLOB |0 |.text |HTFTPLoad
[1973] | 353648| 6232|FUNC |GLOB |0 |.text |printfile
[1560] | 195580| 6236|FUNC |GLOB |0 |.text |getfile
[803] | 699204| 6284|FUNC |LOCL |0 |.text |read_article
[368] | 500992| 6288|FUNC |LOCL |0 |.text
|LYUCFullyTranslateString_1
[1100] | 507428| 6884|FUNC |GLOB |0 |.text |LYHandleMETA
[2126] | 205248| 7936|FUNC |GLOB |0 |.text |main
[92] | 213324| 8016|FUNC |LOCL |0 |.text |parse_arg
[2020] | 711056| 8356|FUNC |GLOB |0 |.text |HTLoadNews
[2220] | 273800| 8812|FUNC |GLOB |0 |.text |highlight
[381] | 524420| 9116|FUNC |LOCL |0 |.text
|LYProcessSetCookies
[1359] | 328376| 9476|FUNC |GLOB |0 |.text |read_cfg
[2224] | 183764| 9716|FUNC |GLOB |0 |.text |HText_SubmitForm
[219] | 426976| 11652|FUNC |LOCL |0 |.text |HTML_end_element
[1984] | 629964| 12096|FUNC |GLOB |0 |.text |SGML_character
[2267] | 565128| 12116|FUNC |GLOB |0 |.text |HTLoadHTTP
[2286] | 306132| 12340|FUNC |GLOB |0 |.text |options
[499] | 1069176| 15008|OBJT |LOCL |0 |.data |repl_map
[436] | 1114568| 15128|OBJT |LOCL |0 |.data |repl_map_mnemonic
[471] | 1098544| 15752|OBJT |LOCL |0 |.data
|repl_map_mnemonic_ascii_0
[767] | 673560| 16088|FUNC |LOCL |0 |.text
|HTMIME_put_character
[1449] | 222320| 43052|FUNC |GLOB |0 |.text |mainloop
[1613] | 1186244| 45056|OBJT |GLOB |0 |.bss |history
[215] | 378888| 48088|FUNC |LOCL |0 |.text |HTML_start_element
[1942] | 1236268| 49152|OBJT |GLOB |0 |.bss |links
Note the sizes of history[] and links[], they are controlled by MAXHIST
and MAXLINKS.
> So just remove from src/makefile.dos the object files you don't need.
And comment out the appropriate things from the GLOBALREF and
HTRegisterProtocol stuff in HTAccess.c and LYMain.c, for a start.
> If hand editing is no problem for you, you could "trim the fat" from chrtrans
> tables.
Yes. See src/chrtrans/README.tables. (That is where the repl_map* stuff
above is coming from.)
> In a recent post, Fote pointed out a chunk of code that isn't a must.
Not a significant contribution to the size, and only some of that is new:
$ nm -s lynx|sort -n -2 +3|egrep 'HTMLGen|HTMLParse|Preparse'
[708] | 0| 0|FILE |LOCL |0 |ABS |HTMLGen.c
[2181] | 1050302| 1|OBJT |GLOB |0 |.data |LYPreparsedSource
[722] | 652220| 20|FUNC |LOCL |0 |.text |HTMLGen_abort
[711] | 955512| 36|OBJT |LOCL |0 |.rodata |HTMLGeneration
[713] | 651112| 56|FUNC |LOCL |0 |.text |HTMLGen_put_string
[720] | 651168| 56|FUNC |LOCL |0 |.text |HTMLGen_write
[721] | 650080| 64|FUNC |LOCL |0 |.text |HTMLGen_flush
[717] | 652108| 76|FUNC |LOCL |0 |.text |HTMLGen_free
[714] | 652016| 92|FUNC |LOCL |0 |.text |HTMLGen_put_entity
[1663] | 452984| 124|FUNC |GLOB |0 |.text
|HTPreparsedFormatInit
[716] | 651832| 184|FUNC |LOCL |0 |.text
|HTMLGen_end_element
[1773] | 442912| 308|FUNC |GLOB |0 |.text |HTMLParsedPresent
[1780] | 652260| 360|FUNC |GLOB |0 |.text |HTMLGenerator
[710] | 651224| 608|FUNC |LOCL |0 |.text
|HTMLGen_start_element
[709] | 650276| 836|FUNC |LOCL |0 |.text
|HTMLGen_put_character
> Heavy optimization (e.g., O4) helps, but I'm not sure if you can compile
> at that level with the current code. (It wasn't possible, on SunOS4 using
> gcc, _about 3 months ago_.) Linking to shared libraries reduces the size of
> the Lynx image itself, but I'm not sure that will help you (if you can even
> do it on DOS).
>
> > If I can get the size from the current 920K to around 500K, everything
I doubt that all these sizes ar good measurements for judging how much memory
you will need to run Lynx in a reasonable way. A lot of dynamically allocated
memory is used.
> If you succeed, I'm still VERY interested in how to do it. It once was
> possible to get an image less than 400kB, but that would be more like
> 600kB with the more functional Lynx of today. Please post your results.
Maybe ask the minix guy...
Klaus
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;