Foundation’s current archival and serialization APIs (
NSPropertyListSerialization, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.
- It aims to provide a solution for the archival of Swift
- It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist
The Precision 5520 was supplied by Dell for this review. It features a 4K IGZO display, 32GB of RAM, Intel Xeon processor, NVIDIA Quadro graphics and 512GB of Class 50 solid-state drive (SSD).
The starting price for the Precision 5520 is $1,399. The unit we evaluated in this review retails for $2,867.
It also has room for a second hard drive or SSD, real function keys, a T arrow key arrangement, and a trackpad that clicks. It is about the same weight as the 2012 Retina MacBook Pro and gets the same battery life (7 hours).
The most similar Mac is a $3,099 MacBook Pro with a lower resolution display, 16 GB of RAM (max), a 2.9 GHz i7, and a Radeon Pro 460.
When LinkedIn embraced Swift and rebuilt its flagship iOS app using (mostly) Swift, I spent a good amount of time profiling the new compiler characteristics. At that time (mid 2015), it was clear that the compiler was CPU-bound (I/O and memory had no visible impact on build speed). However, the build times were determined primarily by the number of cores and threads available to the compiler, more so than by the CPU clock speed.
Based on this analysis, we decided to use 12-core MacPros for core development, and we saw a significant (2-3 times) speedup of our builds compared with quad-core laptops.
As you can see, 12-core MacPro is indeed the slowest machine to build our code with Swift, and going from the default 24 jobs setting down to only 5 threads improves compilation time by 23%. Due to this, even a 2-core MacMini ($1,399.00) builds faster than the 12-cores MacPro ($6,999.00).
For machines with more than 4 cores consider reducing number of concurrent jobs allowed for Xcode - until the concurrency issue described above has been resolved.
Be careful with disabling Spotlight indexing for ~/Library/Developer as it will also exclude dSYM symbol files of builds and archives.
Xcode uses Spotlight to search for matching dSYM files when symbolicating crash reports. Turning off Spotlight indexing for them might break crash symbolication completely.
This smells like a hardware or kernel issue.
Blaming any particular component is premature. “There Is A Bug Exposed By Swift 3 Running on Sierra” is all we know.
Core count doesn’t seem to matter either, we observed the same issue on 4-core Xeon setups. Seems to be Xeon-specific.
The bug report is here.
See also: Colin Cornaby.
Guetzli [guɛtsli] — cookie in Swiss German — is a JPEG encoder for digital images and web graphics that can enable faster online experiences by producing smaller JPEG files while still maintaining compatibility with existing browsers, image processing applications and the JPEG standard. From the practical viewpoint this is very similar to our Zopfli algorithm, which produces smaller PNG and gzip files without needing to introduce a new format; and different than the techniques used in RNN-based image compression, RAISR, and WebP, which all need client and ecosystem changes for compression gains at internet scale.
Guetzli specifically targets the quantization stage in which the more visual quality loss is introduced, the smaller the resulting file. Guetzli strikes a balance between minimal loss and file size by employing a search algorithm that tries to overcome the difference between the psychovisual modeling of JPEG's format, and Guetzli’s psychovisual model, which approximates color perception and visual masking in a more thorough and detailed way than what is achievable by simpler color transforms and the discrete cosine transform.