Marcel Weiher mpw

This is a reference of all the useful links to follow my UIKonf'17 talk on Code Generation in Swift

Slides on SpeakerDeck
Keynote Live URL
All the other files in this GIST contains the code snippets I used in my slides, referenced by slide number.

Async/Await for Swift

Proposal: SE-XXXX
Authors: Chris Lattner, Joe Groff

Introduction

Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.

This paper introduces a first class Coroutine model to Swift. Functions can opt into to being async, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

State of String: ABI, Performance, Ergonomics, and You!

Hello, I’ve been working on implementing, optimizing, and improving String in preparation for ABI stability, and I thought I’d share the current status of String in Swift 5 and some potential directions to go. This is the product of conversations with open source contributors and my colleagues on the Swift standard library team at Apple.

The primary area of focus is stabilizing String’s ABI, but we’d be remiss if we couldn’t also fit in performance and ergonomic improvements. String’s ergonomics in particular is one area where we think the status quo is woefully inadequate, and over half of this email is devoted to that topic. At the end, there’s a section about a community initiative that we hope can help users of String as well as guide future development.

(Note: I’m sending this to swift-dev because much of the contents revolve around implementation concerns. I’ll also cross-reference on swift-evolution and swift-users. See also the [StringManife

DEPRECATED for Xcode 10 🎈

(check out What's New in Swift at 11:40, slide 42)

Whole Module Compilation Optimizations: Why these terms are sometimes misleading

When you look up how to compile swift faster for debug builds, people very earnestly give advice that seems contradictory: you should "try using the whole module optimization flag," and also "never use whole module optimization for debugging". [^1]

This is confusing because some of us are using these two general words:

compilation: "turning text into an executable program"

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

	//
	// PSPDFGenerics.h
	// PSPDFFoundation
	//
	// PSPDFKit is the leading cross-platform solution for integrating PDFs into your apps: https://pspdfkit.com.
	// Try it today using our free PDF Viewer app: https://pdfviewer.io/
	//
	// This file is MIT licensed.

	/**

	import Foundation


	struct Event<T> {
	let key: String
	}

	extension Event {
	var notificationName: Notification.Name {
	return Notification.Name(key)

	#import <Foundation/Foundation.h>
	#import <time.h>
	#import <os/lock.h>

	#define ITERS 2000
	#define NSEC_PER_ITER(time) (((double)time * (double)NSEC_PER_SEC) / (double)ITERS)

	#define TEST(body, name) do {\
	start = [NSDate date];\
	for (int i = 0; i < ITERS; i++) {\

	#!/bin/bash

	set -e

	CONTENTS=$(tesseract -c language_model_penalty_non_dict_word=0.8 --tessdata-dir /usr/local/share/tessdata/ "$1" stdout -l eng \| xml esc)

	hex=$((cat <<EOF
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
	<plist version="1.0">