Author: @dm

I spent this weekend traveling, so instead of an article I just want to share a picture of a draft beer that I found in Sweden.

Yeah, it’s name is ‘The Last .IPA‘.

This week I’m gonna throw three strategies you can use to improve the performance of your NSPredicates — either in Core Data or while filtering a collection like NSArray.

If things are really slow though, there are probably other places where you should be focusing, but let’s assume you have already done that. 😉

Avoid Wildcards

The convenience of throwing a star wildcard (*) to look for a prefix, suffix or substring can make your predicates slower. Instead of using title LIKE "The *" use

title BEGINSWITH "The"

Instead of term LIKE *someSuffix" use

term ENDSWITH "someSuffix"

If you are looking for the occurrence of a substring within a string, don’t use term MATCHES '*anything*', there is a super cool keyword exactly for that:

term  CONTAINS "anything"

Cheap Computations First

Unlike you, your iPhone’s little brain is faster crunching math than processing text.

Perform the operations with numbers first (this includes NSDate) and leave the NSString comparisons at the end of the predicate.

Discard largest groups first

Place the comparisons that will eliminate the largest group of data at the beginning of the predicate. This leaves a smaller number of objects for the next comparisons (which should be the most expensive comparisons).

For this week I want to share a concept and an example repository of something called Cellular Automata.

To be honest, it’s one of those simple things with a big name. Let me explain:

Imagine a grid of cells. Each cell has a finite number of states (let’s say 0 or 1 at its most basic case).
The system has an initial configuration for each cell (input) and changes over time according to some fixed rules. These rules determine the new state of each cell in terms of its current state and the state of the cells surrounding it (called neighbors). Finally, a particular state in time of the grid is called generation.

And this is how a two dimensional cellular automata looks (know that they can happen in any number of dimensions):

Indeed! With some imagination they do look like cells partying like it’s Friday!

This particular example is called ‘Game of Life’. It is a popular cellular automaton proposed by John Conway in 1970 and, using two basic rules, can generate groups of cells with lots of different behaviors.

If you want to see how the animation was coded, check out the code of the repository (iOS application) or if you are interested in the topic, I suggest the first chapter of the book ‘Game of Life Cellular Automata’ by Andrew Adamatzky.

As usual, this repository is licensed under the MIT License.

If you debug solely through NSLog you are missing the better insight the debugger can provide you. Also, it is easy to forget all those logging functions, ship them into production and, depending on the industry, even introduce security risks.

On the other hand, if you are using only basic breakpoints you might find yourself typing po <object> just too often.

This is where breakpoint actions come handy: you can configure breakpoints that execute debugger commands like printing variables. To do so:

1. Right click on any pointer and select Edit Breakpoint….
2. Then, select Debugger Command from the Action menu and type a command to some variable in the scope of the selected breakpoint. For example: po sender to print the debug description of an object identified as ‘sender’ or p selectedSegment to print the value of an atomic variable named ‘selectedSegment’. If you feel in a verbose mood and need to output lots of stuff, you can click the ‘+’ button and add more commands with more prints.
3. By selecting the option Automatically continue after evaluating, the breakpoint doesn’t stop the execution of the program and behaves like an elegant version of NSLog that keeps your code clean.