davbeck

Swift build time profiling

Linkdin (of all companies) published a shocking blog today on the performance of Swift build times. They claim that their project compiles faster on their lower speced MacBook Pros (and even a Mac mini) than their 12 core Mac Pros. Even though the Mac Pro is 4 years out of date, the raw number of cores gives it quit an advantage over the 4 core MacBook Pro and especially the 2 core Mac mini. What's even more shocking, is that when they lowered the number of threads available to the compiler, their build times actually went up. It's an interesting article and worth reading. I decided to test their numbers with my own project.

First, I tried building from the command line, cleaning each time to get consistent results:

time xcodebuild -workspace Engagement.xcworkspace -scheme Engagement -sdk iphoneos -configuration Debug clean build | xcpretty

davbeck

Async Await

I love this proposal so much. Much of it is exactly how I’ve thought Swift’s concurrency model should look over the last year.

Making async a return attribute just like throws seems like the right solution to me. Building on top of callbacks (rather than introducing futures/promises) is also the right approach for swift. I think this proposal nails the problem right on the head: callbacks don't work well with the rest of Swift's error handling, is awkward, error prone, and yes, looks ugly.

One point that I've gone back and forth on is how strictly to enforce excecution order. For instance, in this example. it would make sense to allow the first 2 lines to excecute in parallel and excecute the third line once they both complete:

let a = await foo()

davbeck

import UIKit


extension UIViewContentMode: CustomStringConvertible {
	public var description: String {
		switch self {
		case .scaleToFill:
			return "scaleToFill"
		case .scaleAspectFit:
			return "scaleAspectFit"

davbeck

import Foundation
import JavaScriptCore


/// Used to lookup our Bundle.
private class MomentBundleClass: NSObject {}


/// A wrapper around a moment.js object.
public struct Moment {

davbeck

!function(t){var n={};function r(e){if(n[e])return n[e].exports;var i=n[e]={i:e,l:!1,exports:{}};return t[e].call(i.exports,i,i.exports,r),i.l=!0,i.exports}r.m=t,r.c=n,r.d=function(t,n,e){r.o(t,n)||Object.defineProperty(t,n,{configurable:!1,enumerable:!0,get:e})},r.n=function(t){var n=t&&t.__esModule?function(){return t.default}:function(){return t};return r.d(n,"a",n),n},r.o=function(t,n){return Object.prototype.hasOwnProperty.call(t,n)},r.p="",r(r.s=125)}([function(t,n,r){var e=r(2),i=r(21),o=r(12),u=r(13),c=r(18),a=function(t,n,r){var f,s,l,h,v=t&a.F,p=t&a.G,d=t&a.S,g=t&a.P,y=t&a.B,m=p?e:d?e[n]||(e[n]={}):(e[n]||{}).prototype,b=p?i:i[n]||(i[n]={}),x=b.prototype||(b.prototype={});for(f in p&&(r=n),r)l=((s=!v&&m&&void 0!==m[f])?m:r)[f],h=y&&s?c(l,e):g&&"function"==typeof l?c(Function.call,l):l,m&&u(m,f,l,t&a.U),b[f]!=l&&o(b,f,h),g&&x[f]!=l&&(x[f]=l)};e.core=i,a.F=1,a.G=2,a.S=4,a.P=8,a.B=16,a.W=32,a.U=64,a.R=128,t.exports=a},function(t,n,r){var e=r(4);t.exports=function(t){if(!e(t))throw TypeError(t+" is not 

davbeck

// original:
Query("SELECT * FROM example WHERE e_uuid = $1;", idA)
// or
Query("SELECT * FROM example WHERE e_uuid = $1;", [idA])

// manual interpolation test:
var query = Query(stringInterpolation: {
	var temp = Query.StringInterpolation(totalLiteralSize: 40, interpolationCount: 1)
	temp.appendLiteral("SELECT * FROM example WHERE e_uuid = ")
	temp.appendInterpolation(idA)

davbeck

import Foundation


extension Data {
	/// JWT strips the padding off the end of the base64 string
	fileprivate init?(jwtPart: String) {
		var paddingCount = 4 - jwtPart.count % 4
		if paddingCount == 4 {
			paddingCount = 0
		}

davbeck

import Foundation
import SQLite3


public enum SQLiteError: Error, LocalizedError {
	case sqlite(code: Int32, message: String?)
	case invalidDatabase
	case invalidStatement
	case invalidUTF8String
	

davbeck

UICollectionViewDiffableDataSource does an excellent job of handling changes to data and updating the items accordingly. However, there seems to be no good way to handle updates to existing items. If you follow the samples that Apple provides and define Equatable and Hashable to use an id instead of the complete models value, value changes won't cause the collection view to update those cells. If you leave Equatable as it should be and have it compare all values of a model, the cell will update, but it will completely replace the old cell, causing an undesirable "flash".

UICollectionViewComparableDataSource wraps a UICollectionViewDiffableDataSource and will check for items that have been updated, but not removed or added.

This allows us to make updates to a cell without completely reloading it. This is especially usefull if your cells have some sort of temporary state.

This is just an expirement. Use at your own risk.

davbeck

// adapted from https://github.com/raywenderlich/swift-algorithm-club/tree/master/Binary%20Search

/// The result of a binary search.
struct BinarySearchResult<Index> {
	/// The index for the searched key.
	///
	/// Use this to either insert new values while maintaining the sort order of the collection, or to lookup the value if `isPresent` is true.
	var index: Index
	
	/// Whether the key was found in the collection.