Re: setup w/char* eliminated is big

[ptsekov at syntrex dot com]

Well, after looking at the code for some time and playing with it i finally 
discovered that the purpose for the 100kb increment is not the String class but 
this:

This is taken from the Changelog for v.2.47 of the Makefile.in

Backout -fno-exceptions option.

This explains it all! No need to worry ;)) Bad thing is I havent looked at the 
Makefile.in first,
but spent time looking at assembly shite ;)))

Quoting Robert Collins <robert.collins@itdomain.com.au>:

> Well, 11K (i.e. 2 seconds download at 56Kbit) is neither here nor
> there.
> 100K is more of an issue.
> 
> Anyway, Chris' response (AFAICT) implied that the size was not an
> issue,
> but cross-compilability was.
> 
> Rob
> 
> 
> ===
> ----- Original Message -----
> From: "Gary R. Van Sickle" <g.r.vansickle@worldnet.att.net>
> To: <cygwin-apps@sources.redhat.com>
> Sent: Saturday, February 16, 2002 6:20 PM
> Subject: RE: setup w/char* eliminated is big
> 
> 
> > > -----Original Message-----
> > > From: cygwin-apps-owner@cygwin.com
> > > [mailto:cygwin-apps-owner@cygwin.com]On Behalf Of Pavel Tsekov
> > > Sent: Friday, February 15, 2002 10:05 AM
> > >
> > > Robert Collins wrote:
> > >
> > > > Ok,
> > > >  finally got some breathing time.
> > > >
> > > > Setup with char * eliminated is ~350K. Ouch.
> > > >
> > > > This is why I've not committed my patch yet (I've been trying to
> see
> > > > *where* the extra 100K appeared from).
> > >
> > >
> > > You have four 'inline' - I know they're small in size, but three
> of
> them
> > > are the most commonly used methods (the default and the copy
> constructor
> > > and also the 'operator ='). Remove the 'inline' modifier and see
> if
> the
> > > executable gets smaller.
> > >
> >
> > Done and done:
> >
> > CVS + "For the curious" patch + Two subsequent patches from Michael
> Chase ==
> > 355840 bytes.
> > Above with all inlines "un-inlined" == 344576 bytes.
> >
> > So a bit over 11KB saved.  In my judgement that's enough to warrant
> removing the
> > inlines; if string-handling speed is a significant factor for
> setup.exe I'd say
> > there's something wrong somewhere that no amount of inlines could
> remedy.
> >
> > --
> > Gary R. Van Sickle
> > Brewer.  Patriot.
> >
> >
> 
>