Eigenstate: myrddin-dev mailing list

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

Re: Smaller binary size


On Fri, 1 Dec 2017 12:02:55 +0800, nml <arumakanil@xxxxxxxxx> wrote:

> On 1 December 2017 at 11:28, Andrew Chambers <andrewchamberss@xxxxxxxxx>
> wrote:
> 
> > You don't need to split the code into smaller packages for smaller linking
> > just into different .o files. Musl libc does this, the init calls are a
> > different story though.
> >
> Hi Andrew,
> 
> We can safely remove all the init calls asoocated with it if the package
> can be proved to be unused,.

Eh, sort of. This is hard. One example is libescfmt, but we also
have hooks in libstd so that libthread can install mutexes. Is that
a package being unused?

So, yeah, if we don't even link the package, there's no __init__.
But once there's a single 'use', the '__init__' needs to get called.

> But within a package, we have to keep all init calls (and all their
> downstream referenced symbols) even if the involed APIs are not used at
> all.
> For example, the hello-world doesn't need a DNS resolver but it has to be
> kept because we cannot guarrantee if the init calls have any side-effect
> and some APIs may depend on that.
> That's why I started to think of fine-grained std at first.
> 
> The lazy init approach that ori mentiioned earlier is a bit of ad-hoc to my
> taste if I understand it correctly (That is, adding them to the entry point
> of each API that depends on that init).
> It's suitable for some scenarios but not all.
> I am still comtemplating for a win-win solution that does not need to break
> the std into pieces.

Just as a heads up, I just implemented the lazy loading for the
resolver -- it cut the binary size down significantly for a hello
world program. Now, we're down to 95k of text, and 20k or so of
data+bss. The vast bulk of that is to do with the formatting code
pulled in by std.put.

It's now pushed.

-- 
    Ori Bernstein

Follow-Ups:
Re: Smaller binary sizenml <arumakanil@xxxxxxxxx>
References:
Re: Smaller binary sizenml <arumakanil@xxxxxxxxx>
Re: Smaller binary sizeAndrew Chambers <andrewchamberss@xxxxxxxxx>
Re: Smaller binary sizenml <arumakanil@xxxxxxxxx>