These days, my day job is all about optimizing email deliverability, but I am fascinated by making computers faster. Originally, that was even the focus of the company I cofounded (until we pivoted to emails—got to pay the rent!). I still believe that the way we’ve built the computing ecosystem is fundamentally flawed and, in many ways, disempowering.

My focus in on the JVM (despite the JVM being undervalued by a lot) but the techniques are architecture independant (e.g. x86, ARM, Python, Javascript).

This post is to share a few reasons why I think so—the small bits of evidence that keep me fascinated by performance and make me question the status quo.

I’m just one guy working from home and I’m sharing these ideas in hopes of kickstarting a conversation.

Result 1: 30% Faster Startup for Uber

One of my early wins was optimizing Uber’s app startup time by 30% a few years ago (app startup is a key metrics for all Android app). I achieved this by using an automated tool I developed to identify slow sections of the code. The tool could then prove (or disprove) that certain code sections weren’t needed “soon” (a complicated question that would need a few pages to answer) and could be moved to run asynchronously.

Result 2: A 3x Faster Android ui

I applied the same core algorithm to detecting “too coarse” synchronized blocks (e.g. synchronizing a whole instance instead of a field of a field of a field). The result: a 3x speed improvement in Android display speed. It’s because there was a “too coarse synchronized” in a key Android class that is used a lot by most apps (i.e. all Android apps but the ones on Flutter and Unity).

In this case, the resolution wasn’t fully automated because doing so would require analyzing ARM machine code (a bit out of scope for a weekend project).

result 3: A 11% faster lucene

This one was completed last summer. By analyzing the entire program, I removed all dynamic method dispatches (e.g., interfaces) by resolving them at compile time (see my other post about it if you want to learn more). I was genuinely surprised to find a speedup! The gains varied, ranging from 2% to 10%, with an average of around 5% improvement.

(y-axis is time in ns and the x-axis is the number of run – after  a 100K warm up – test program is here https://github.com/manycore-com/experiments)

Moving Forward

I’m honestly not sure what’s next, but I’m excited to explore the possibilities. Because I’m not connected to academia or the industry in any way, it’s difficult to marshall resource to explore these ideas more fully (i.e. when I pitched VC they were laughing at me). Maybe I’ll do a deeper write-up of my methods and release some of the tools as open source.

If I could get these results, with no formal background in these areas, it suggests a deeper industry problem: we’re leaving a lot of performance on the table because it’s in the interest of all stakeholders.

I’d love to collaborate or get feedback on these approaches. Email me!