Deep iOS Performance Optimization: Time Complexity, GCD, Thread Monitoring, and Method Hooking

When a feature is exposed as a public API, even seemingly small data sets can cause significant performance degradation, so optimizing algorithmic time‑complexity becomes crucial.

The article illustrates common complexities with examples: O(1) direct array access, O(n) linear scans, and O(n²) duplicate detection, emphasizing that O(n) is a practical threshold for public interfaces.

For iOS collections, NSArray/NSMutableArray operations like containsObject: , indexOfObject: are O(n), while objectAtIndex: , firstObject , addObject: are O(1); binary search methods such as indexOfObject:inSortedRange:options:usingComparator: are O(log n).

NSSet/NSMutableSet/NSCountedSet and NSDictionary/NSMutableDictionary provide O(1) for add, remove, and lookup because they are hash‑based, though keys must conform to NSCopying .

To keep the UI responsive, the article recommends off‑loading heavy work to background queues using GCD, while cautioning against thread explosion and deadlocks. Safe patterns include using serial queues, limiting NSOperationQueue.maxConcurrentOperationCount , and preferring dispatch_apply or dispatch_semaphore to control concurrency.

Crash logs for various thread states (idle, active, main) are shown to illustrate how to diagnose threading issues.

Because I/O is a major power consumer, the article suggests batching writes, using appropriate APIs, selecting suitable threads, and caching with NSCache to reduce I/O frequency.

Location services also affect wake‑up frequency; the article compares continuous updates ( startUpdatingLocation ) with deferred updates, significant‑change monitoring, and region monitoring, recommending the latter two for energy efficiency.

Memory reclamation can pause the UI, so the author advises minimizing large, sudden allocations.

General performance‑prevention principles include reducing algorithmic complexity, stopping unnecessary background work during UI interaction, setting appropriate QoS, merging timers, and aiming for 60 fps rendering or sub‑100 ms response times.

For runtime monitoring, a CFRunLoopObserverCreate is used to observe the main run‑loop, while a secondary thread samples the run‑loop state every 16‑20 µs to detect stalls based on BeforeSources and AfterWaiting transitions.

Stack trace collection uses task_threads and thread_info to retrieve each thread’s state, then builds a linked list of SMStackFrame structures to record return addresses.

Symbolication maps these addresses back to method names by locating the appropriate __LINKEDIT segment, reading the symbol and string tables, and calculating the offset from the image slide.

To record method call hierarchies, the article defines CallRecord and ThreadCallStack structs, storing object, selector, and timing data, and uses pthread_setspecific to bind a stack to each thread.

Hooking objc_msgSend on arm64 is demonstrated with inline assembly that saves registers, invokes a pre‑hook, calls the original implementation, then runs a post‑hook, preserving the call stack and return value.

Various timing functions are compared: NSDate , clock_t , CFAbsoluteTime , CACurrentMediaTime , and mach_absolute_time , noting the difference between wall‑clock and monotonic clocks.

Finally, the techniques are integrated into a demo called DecoupleDemo , where invoking [[SMLagMonitor shareInstance] beginMonitor] starts monitoring and [SMCallTrace start] begins method‑call tracing, with configurable depth and minimum duration filters.