over|yonder Discuss a problem ↗

We make tech faster

Optimization through the computing stack A sequence moves through grouped performance intervention domains: product architecture, data and execution, runtime and toolchain, operating systems, machine architecture and custom hardware. 1 s 100 ms 10 ms 1 ms 100 µs 10 µs PRODUCT AND ARCHITECTURE DATA AND EXECUTION RUNTIME AND TOOLCHAIN OPERATING SYSTEM AND SERVICES MACHINE ARCHITECTURE CUSTOM HARDWARE Workflow / productdelete redundant workflow steps System / distributioncollapse synchronous service hops Algorithmhoist invariants out of hot loops Data model / query planpush predicates into storage scans Data structure / access patternreplace scans with indexed lookups Allocation / garbage collectionreuse arena storage in hot paths Data layout / localitypack hot fields into contiguous arrays Concurrency / synchronizationshard locks; remove contention Language runtime / virtual machinespecialize hot-path dispatch Compiler / code generationfuse and vectorize hot kernels Storage / filesystem / I/Obatch I/O; eliminate seeks and copies Network / interprocess callscoalesce RPCs; compress wire payloads Operating system / schedulerbatch syscalls; keep state in kernel Instruction set / vector executionpack data into SIMD lanes Microarchitecture / cache / memorytile working sets to fit cache Graphics processor / acceleratormap independent work across GPU lanes Reconfigurable logic / FPGApipeline a dedicated datapath Application-specific silicon / ASIChardwire the critical datapath
From product architecture to custom silicon, depending on what the problem needs.

Why performance?

Slow software gets in the way of using it. You lose your place waiting for a search, or work around a feature because it takes too long. As the workload grows, buying faster hardware can become an expensive habit.

We investigate those delays and fix the code behind them. That can make a product more responsive or let it handle more work on the hardware you already have. The projects below show what that looks like in practice.

Selected engineering work.

rstat

eBPF Linux system monitor for sub-millisecond CPU, memory and process telemetry.

Read the case study ↗
Shell + service callStarted command-line tools and waited on the power-profile service for every update.
~800 ms
Long-running Rust collectorKept state in memory, read power directly and combined three process scans into one.
~15 ms
Kernel-assisted collectoreBPF accounts during scheduler events; userspace reads the accumulated counters in a batch.
0.16 ms avg
0.1 ms1 ms10 ms100 ms1 s

Rake

Compiler engineering for a vector-first kernel programming language.

Visit Rake ↗

Graphics

Specialist real-time graphics and visualisation across CPU threads, GPU queues and dedicated hardware engines.

Explore our graphics work ↗

Engineered by

Kieran Hannigan

BSc, MPE, MBA, MIEAust (Fmr), GAICD

Kieran completed a bachelor’s degree in Engineering Science and Computer Science and a master’s degree in Electrical and Electronic Engineering focused on semiconductor physics, both at UWA. He went on to a career in electrical engineering in the buildings sector of the construction industry, focusing on critical power and integrated control systems. That career culminated in leading a national renewable energy team as a Principal Engineer at a 30,000-person firm.

He completed an MBA at AGSM, including an exchange at Tuck, also studied at NUS and CBS, and most recently completed the GAICD before founding over|yonder as a sole proprietor.

Kieran Hannigan

Got a performance bug that’s survived the usual fixes?

Let’s speed things up. ↗ Sydney, Australia · Working worldwide