Size of the swift runtime and minimal app

Using Swift
1

Hi,

What's the size of the swift runtime and also a minimal hello world type of app?

2

I assume you mean a command-line app, never built a Swift GUI app. It is not hard to check this for yourself, here are the commands I ran on Ubuntu 20.04:

> ./swift-5.3.1-RELEASE-ubuntu20.04/usr/bin/swiftc -O swift/swift/test/Interpreter/hello_toplevel.swift
> ls -l hello_toplevel
-rwxrwxr-x 1 butta butta 15184 Dec 12 03:52 hello_toplevel

Interestingly, the unoptimized version is slightly smaller, there's also the -Osize flag.

> readelf -d hello_toplevel | ag libswift
 0x0000000000000001 (NEEDED)             Shared library: [libswiftCore.so]
> ls -l swift-5.3.1-RELEASE-ubuntu20.04/usr/lib/swift/linux/libswiftCore.so
-rwxr-xr-x 1 butta butta 7850184 Nov 12 10:51 swift-5.3.1-RELEASE-ubuntu20.04/usr/lib/swift/linux/libswiftCore.so

So the usual answers to your questions are 7,850,184 and 15,184 bytes. Since that's a shared library, it depends on several other non-Swift libraries like libicu, libpthread, and so on.

Alternately, you can statically compile in the stdlib and libicu:

> ./swift-5.3.1-RELEASE-ubuntu20.04/usr/bin/swiftc -O -static-stdlib swift/swift/test/Interpreter/hello_toplevel.swift
> ls -l hello_toplevel
-rwxrwxr-x 1 butta butta 36223720 Dec 12 04:17 hello_toplevel

Most of that is probably libicudata, which is almost 28 MB. Maybe LTO could get rid of other unneeded functions.

3 Likes
3

If you care about code size (e.g. doing embedded systems development) then I'd recommend building teh stdlib without unicode / ICU support. I'd get in touch with the Swift for Arduino folks about this for example. They're a friendly and great bunch.

9 Likes
4

Statically linking Swift standard libraries into a release build of my app (a daemon for an embedded board) is about 48MB on arm64 after stripping (actual target is armv7).

I have 4MB flash to play with.

I guess I'm probably not going to shrink it by an order of magnitude? :slight_smile:

1 Like
5

There are two parts here:

  • Not embedding parts stemming from unused parts of your source.
  • Discarding unused parts of statically linked libraries (LLVM has the “lto” option for such an optimization).

To my knowledge the first optimization is active (presumably not for all compiler configurations), but the second optimization is not available. It would indeed be nice to know if such an optimization can be activated, or if anything is planned in this direction, and what parts could then be discarded.

Of course the second optimization is more important for non-Apple platforms, as on Apple platforms the libraries are part of the operating system (see this forums topic about static linking on macOS).

(Note that on Linux, you have two choices for static linking: -Xswiftc -static-executable for statically linking “everything”, my understanding is that this includes other Linux packages that are needed so you do not need to install those when you are running the program, or -Xswiftc -static-stdlib for the Swift standard libraries only. There is no static linking on Windows yet.)

1 Like
6

An experimental implementation of this is available, see the corresponding topic for more details.

7

Do you use Foundation? If not, linking the Swift stdlib alone shouldn't be so bad, 7.5 MB for "hello world" last I checked, which you can probably strip down further with the optimizations @sspringer mentioned.

8

Yeah, I'm using Foundation for Data and also CFSocket (although that dependency I can get rid of). But also AsyncAlgorithms, AsyncExtensions, and a few of my own libraries. I'll have a go at thinning it at some point...

9

If you can get rid of the Foundation dependency entirely, that may help a lot, as that pulls in libicu and the massive icudata library. Async is part of the stdlib, so should be fine.

10

Yeah, until there are replacements for:

  • UUID
  • Data
  • TimeInterval

I'm going to hard-pressed to eliminate the Foundation dependency.

11

The problem is that while the portions of libicu needed for the Swift stdlib have been brought in-house and that dependency removed, the same has not been done for swift-corelibs-foundation, which I've been told only requires it for calendar data and maybe a few other small things.

If you don't need the parts of Foundation that rely on libicu, maybe you can build it yourself with that libicu dependency stripped out. A pull with such a build option would benefit others in the future too, who want to strip libicu out completely.

12

I should probably just take a look at the new FoundationEssentials...

2 Likes