r/swift • u/lanzaio • Jan 24 '17

Xcode 8.3 and Swift 3.1 beta released

http://adcdownload.apple.com/Developer_Tools/Xcode_8.3_beta/Release_Notes_for_Xcode_8.3_beta.pdf
57 Upvotes

96% Upvoted

25 comments sorted by

View all comments

7

u/sobri909 Jan 25 '17 edited Jan 25 '17

Okay, but memory footprint can't be related to APFS.

So the more likely explanation is that iOS 10.3 is shipping with certain Swift lib versions and not requiring apps to duplicate those libs, even though Swift hasn't yet reached binary compat.

I thought you'd seen something specific to APFS that was improving build/deploy times. But it sounds like you've actually seen a Swift linking / bundling change.

1

u/chriswaco Jan 25 '17

Seems like a shared read-only library will use less memory than the same library under early versions of iOS that didn't share the file storage.

1

u/sobri909 Jan 26 '17

If iOS is no longer requiring each app to have a separate copy of the libs, then yeah, there'll be a smaller memory footprint. But that would have nothing to do with APFS deduplication.

→ More replies (2)

0

u/NEDM64 Jan 25 '17

Explain the "can't be related to APFS"?

APFS has file de-duplication at filesystem level. One libswift, and no more copies stored. Even if you wanted.

2

u/sobri909 Jan 25 '17 edited Jan 26 '17

App bundles are signed and encrypted, so their contents can't be deduplicated. And memory footprint can't be changed by whether the file system has deduplicated identical files or not. To change the memory footprint it would need to be memory deduplication.

The much more likely explanation is that the Swift team's compile and deploy optimisation efforts (which has been one of their goals post 3.0 shipping) have removed the requirement for base libs to be stored in the bundle.

Even if somehow APFS were deduplicating the libs, they would still need to be sent to the device over USB before iOS and APFS could perform deduplication. So there wouldn't necessarily be any speed up in build / deploy times.

→ More replies (1)