lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev bloating binaries (was clue)


From: Klaus Weide
Subject: Re: lynx-dev bloating binaries (was clue)
Date: Thu, 25 Feb 1999 22:43:30 -0600 (CST)

On Fri, 26 Feb 1999, Henry Nelson wrote:

> > Do you have a list of "features" you want to see as compile time options
> 
> Because of the total commercialization of the WWW, I can see no use
> for the send a C)omment function. If it were my ball game, I wouldn't
> even waste a compile time option on it; I would unravel it and trash
> it forever. In this day and age, any webmaster who really wants to
> get comments will have a link on his page. The C)omment function is
> a nuisance to people teaching novices how to use Lynx. Anyone with
> enough expertise to make a valid comment on a page would know how
> to effectively use the P)rint function. Getting rid of the C)omment
> function would free a key for much more important functions.

Not much code savings to be had from this though - the bulk of mailto
handling is in the same function, whether it is invoked by 'C' or
following a mailto: link.  

> To mention this is unfair since Jim is already working on it, but as
> an example of the humongous amount of debugging code, there needs to
> be a way to turn off CTRACE and TRACE. The saving in binary size is
> significant. In _release_ (production-level) code sets, the toggle to
> turn trace on/off should not be compiled in as the default.

I disagree with that.  Many questions to this list would have to be replied
to with "First get a version that has the TRACE feature, then...", instead
of just "Turn TRACE on".

That isn't to say that it shouldn't be *possible* to disable TRACE code
at compilation.

> There are dozens of examples like the "discovery" by Klaus of the WWW
> rules code. Be honest people, how many of you are going to use that
> code? My guess is 10 or 20 max, worldwide. NO_RULE doesn't work as far
                                                    ^S
> as I can see (see appended patch). 

Yes, I overlooked the HTTranslate call there, sorry.

As far as I can see, the function HTAA_checkAuthorization() and maybe
the whole of HTAAServ.c isn't being used - I haven't tested it.
But maybe you could extend the range if the #ifndef to cover basically
the whole file.

That may not result in any improvement in binary size - a decent linker
should not include code from HTAAServ.o in the final executable at all
if no function from it is referenced.

> Anyway, I could see lumping these
> tiny snippets of _expendable_ code into one group of NO_FRILLS, switched
> from off as the default (meaning active code) during development to on
> by default in the (pre-)release code set.
[...] 
> > >> The real problem is that the code only grows. In the last two
> > That is an obvious consequence of adding new features with
> > keeping a compatibility.
> 
> This is so true, and the very reason I have to retract much of what
> I said. My only concern is that (no offense at all meant to Brian or
> anyone else), for example with the cookies code, is 100% of this not in
> the binary when configured for no-cookies? (Again, only asking; I don't
> know.)

I Can't answer that currently.

> Unless you are using shared libraries 

Why would one not?? (I assume you mean libc etc., not libwww)

>                                       I don't know how you do it. On
> Solaris2.6, linking to slang (so the only direction to configure is
> --with-screen=slang) the plain vanilla default binary after running
> strip is:
> -rwxr-xr-x 1 nelsonhe 1207848 Feb 26 09:30 lynx-default
> 
> removing only the rules code:
> -rwxr-xr-x 1 nelsonhe 1203624 Feb 26 09:30 lynx-norules
> 
> removing only the CTRACE debugging code:
> -rwxr-xr-x 1 nelsonhe 1161864 Feb 26 09:30 lynx-nodebug

Jim seems to have reported much bigger savings from removing CTRACE.

[ patch snipped ]

   Klaus

reply via email to

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