Navigating Extreme Memory Pressure
Last year I joined the WikiCamps re-platform project. If you're not familiar with the app, WikiCamps is a travel companion - users are able to explore and contribute to the available sites within a region (such as Australia), add sites to collections (e.g. "want to visit"), add sites to trips, make bookings and much more. It happens to be the #1 paid app in Australia with millions of downloads and hundreds of thousands of monthly active users.
The app uses mapping solutions inside the Explore and Plan views, which are seperate tabs accessible via the bottom navigation bar. These views contain instances of custom markers - many, many hundreds - in addition to displaying polylines to represent trip routes that can cover the whole country, and not necessarily in a way that is computationally efficient. It's an interesting project and the problem-space comes with many novel technical challenges. A number of them are worthy of discussion but the one I would like to focus on here is memory pressure.
If that term is near meaningless to you, memory is a word used to describe a store of data. There are a number of different data stores in modern computers with various scales. On a contemporary desktop computer you install software to a hard disk drive. When that same computer runs software it consumes random access memory. A hard disk drive can be thought of as all the data your machine has, random access memory (what is most often meant when the term 'memory' is invoked) is the amount of data your machine can hold onto at one time, which is most often a significantly smaller amount.
Memory is a scarce resource, even though for higher-end devices it can seem abundant. This has become less obvious over time for many software applications (e.g. we don't need the latest and greatest device in order to make web requests to a banking app) as over a period of several decades device capacity has come to exceed requirements. Today, resource scarcity is perhaps most obvious in the digital games space, where expectations of a universal experience for any device are not considered a realistic aspiration for certain kinds of games, and users are sometimes forced to buy new hardware for the experience they are looking for. WikiCamps sits in an interesting position technically where it bears the burden of some of the challenges that these resource-intensive digital games have while also carrying the expectation of one experience irrespective of device that non-games have.
Back to the challenge. In the lead-up to a release where we would distribute new features that involved increasing the overall memory footprint of our app, profiling (measuring) various devices revealed that the worst-case load scenario was seriously pushing some devices to their absolute limit. Our machines were carrying a lot of weight here. Our solution starts with a simple question: did they really have to? The greatest source of consumption was found to be associated with the maps, and we really only need the maps to consume resources when they are being utilised, i.e. when they are visible. Navigation for the app is managed through tabs with only one tab visible at a time, but importantly for reasons related to user experience we are keeping the views alive (and hence not releasing resources) even when the views are not visible. In principle, we could release resources whenever navigating away from a particular view, and in practice that is exactly what we did.
The result was around a 30% reduction in our memory footprint across various devices and the release went ahead with minimal delay. We were fortunate to have a quick-win like this available to us - once resource constraints become a key consideration in a project they are likely to remain one forever as features are seldom cut or pared back, and it’s not realistic to expect to continue to find large gains over time.
Until next time. 🚀