Big O notation of your app

🇬🇧 Alt Conf on 3 Jun 2019
iOS algorithms performance
Big O notation of your app

Even though you probably spent 5 years studying Computer Science and extensively using asymptotic notation, the truth is in the mobile development world there is a common myth about running time and space requirements being useless.

Modern devices are way more powerful for users to notice a difference between bubble sort and merge sort. Or not? Should everyone know how to implement Ukkonen's algorithm if they develop a weather app? What's the "Big O" of your average app and how to determine it?

I have answers to these questions and by the end of the talk you will have them too.

About this talk

What is this talk about?

Whether Big O matters in everyday iOS apps: can users feel the difference between bubble sort and merge sort on a modern iPhone, and how do you estimate the complexity of your own app?

Why does the deck say Big θ instead of Big O?

Because the difference is the first thing the talk untangles: Big O is an upper bound, Big θ pins the growth rate from both sides - and the Sieve of Eratosthenes makes the distinction concrete.

Which real app problems does it analyse?

Storing data from an API, a path-finding algorithm for drawing connections, snapping an object to the nearest edge, and geohashes for faster local storage - everyday features with a measurable complexity behind them.

Is there a recording?

This page has the London slide deck in the resources section; for a full recording, the NSSpain 2020 edition of the same talk has one embedded on its page.

Related consulting

When an app is slow or crashing in production, this is what I get hired to fix - Instruments traces included.

App Performance & Crashes