Opened 8 years ago

Last modified 6 months ago

#2915 new enhancement

Explore options to reduce binary size of Tor

Reported by: Sebastian Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, modularity, download-size, memory, sponsor8-maybe, 034-triage-20180328, 034-removed-20180328
Cc: erinn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Our bundles are pretty big, so we could benefit from "free" optimizations of binary size (those that don't incur a performance hit). Experimentation with ld's -deadcode flag (OS X) or -ffunction-sections, -fdata-sections together with -gc-sections have led to space savings of up to 25%, which seems well worthwhile.

Child Tickets

Change History (24)

comment:1 Changed 8 years ago by nickm

Sounds positive. Say more about these experiments? Which libraries did you build with -ffunction-sections? I'd bet that the big win would be in dropping the parts of OpenSSL that we don't use, followed by the parts of Libevent we don't use.

Also remember to look at the change in the size of the binary when it's compressed, not in the uncompressed binary, if it's download size that we care most about. :)

comment:2 Changed 8 years ago by ioerror

Are you looking at doing this to all of the binaries in our bundles?

comment:3 Changed 8 years ago by Sebastian

Thanks for reminding me about the gzip, I got the following:

For Linux (note that I didn't manage to compile openssl with -ffunction-sections -fdata-sections here, probably because I didn't try hard enough. so only zlib and libevent are using that option). This leads to a binary that is 150kB smaller when stripped and gzip'd, a space safe of a little over 5%.

For OS X, the -ffunction-sections and -fdata-section options aren't necessary, you just add -dead_strip to LDFLAGS. Here I got 150kB in savings for the stripped and gzip'd binaries, that's over 10%. All in all, I think it's still worth it because it isn't very hard to implement (at least on OS X, openssl on linux/windows might be harder. Not sure).

To answer Jake's question: yes, sure. We should use it for all our binaries if we can.

comment:4 Changed 8 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.3.x-final

comment:5 Changed 8 years ago by nickm

fwiw, I would be okay with merging something that conditionally adds new build options after the merge window for the code itself.

comment:6 Changed 8 years ago by nickm

Also, if somebody can tell me what the options should be and when they should be provided, I can supply the necessary autoconf magic.

comment:7 Changed 8 years ago by Sebastian

On OS X, afaict we need -gfull instead of -g and -dead_strip in LDFLAGS. We might also benefit from -gfull for libevent, since TBB links libevent statically

comment:8 Changed 8 years ago by Sebastian

Thanks to Nick I have an easy patch here I believe. Also, it doesn't seem like using -gfull changes anything, so we should just go ahead and use dead-strip and be happy. That's good news, because it means we don't have to mess with the libs we build. With no libs statically linked, that's a 3% win in binary size, with just libevent linked statically, this gives us an advantage of 5% in terms of binary size, and with libevent and openssl statically linked, we gain over 18% or over 500KB. If this works out OK, this could be pretty neat I think.

comment:9 Changed 8 years ago by Sebastian

Cc: erinn added
Status: newneeds_review

Check out branch osx_deadstrip in my repo. We should probably have erinn try it before merging, I think.

comment:10 Changed 7 years ago by erinn

I tried it. The filesize goes from 3.5mb to 2.9, and tor appears to function normally.

comment:11 Changed 7 years ago by nickm

Merged that. Leaving this open as we look for other options on other platforms.

comment:12 Changed 7 years ago by nickm

Status: needs_reviewnew

Should have taken this out of needs_review though, what with osx_deadstrip already being merged.

comment:13 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:14 Changed 7 years ago by nickm

Keywords: tor-client added

comment:15 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:16 Changed 2 years ago by nickm

Keywords: modularity download-size memory added
Severity: Normal

comment:17 Changed 2 years ago by nickm

Keywords: sponsor8-maybe added

comment:18 Changed 2 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final
Sponsor: Sponsor8-can

comment:19 Changed 22 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:20 Changed 18 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

Deferring various "new"-status enhancement tickets to 0.3.4

comment:21 Changed 16 months ago by nickm

Keywords: 034-triage-20180328 added

comment:22 Changed 16 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:23 Changed 16 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:24 Changed 6 months ago by gaba

Sponsor: Sponsor8-can
Note: See TracTickets for help on using tickets.