This article is more than 1 year old
Axis of evil: Facebook uses Google code to slash page load times
Booting JSON from Android client puts cat vids in front of you in even less time
Facebook has rolled out an open source project from Google to try and improve its ad-slinging performance on Android.
After a six-month implementation of Google's FlatBuffers across its Android client, Facebook reckons it's slashed the time it takes to load stories from the disk cache “from 35ms to 4ms”, slashed transient memory allocations by 75 per cent, reduced overall storage of the client by 15 per cent, and sped up its cold start time by between 10 and 15 per cent.
FlatBuffers is a serialisation library that the Chocolate Factory created to try and get around the mismatch between today's fast processors and the memory subsystem.
Google had mobile game development in mind for FlatBuffers. As it says in its white paper on the library, it wants to handle the problem of serialization with “no temporary objects, no additional allocation, no copying, and good locality”.
FlatBuffers is strictly fielded, and that's what attracted Facebook's attention when it set to work getting better performance out of its Android client.
In particular, what The Social NetworkTM wanted is to handle the subset of a user's social graph that gets pushed to the Android client.
“On mobile clients, we can't download the entire graph, so we download a node and some of its connections as a local tree structure,” Facebook software engineer George Xie writes at Facebook's Code blog.
The partial social graph Facebook sends to Android is a memory challenge
On a better-specced machine, something like JSON works just fine, Xie writes, but on a mobile, both parser initialisation and the act of parsing are slow, and a JSON stream of just 20kB created about 100kB of transient memory, “which placed significant pressure on Java's garbage collector”.
The attraction of FlatBuffers, Xie says, is that it “includes object metadata, allowing direct access to individual subcomponents of the data without having to deserialize the entire object”.
A FlatBuffer data object, he says, starts with a vtable that provides the description of what follows, with pointers to the data fields, as shown below.
The FlatBuffers storage schema lets software access data without deserialisation
It's best, at this point, to directly quote from Xie:
- Each object is separated into two parts: the metadata part (or vtable) on the left of the pivot point and the real data part to the right.
- Each field corresponds to a slot in vtable, which stores the offset of the real data for that field. For example, the first slot of John's vtable has a value of 1, indicating that John's name is stored one byte to the right of John's pivot point.
- For object fields, the offset in vtable would be pointing to the pivot point of the child object. For example, the third slot in John's vtable points to the pivot point of Mary.
- To indicate that no data is present, we can use an offset of 0 in a vtable slot.
The point, he says, is that this structure lets the code fetch data from the FlatBuffer object without needing to create intermediate objects in memory.
// Root object position is normally stored at beginning of flatbuffer.
int johnPosition = FlatBufferHelper.getRootObjectPosition(flatBuffer);
int maryPosition = FlatBufferHelper.getChildObjectPosition(
flatBuffer,
johnPosition, // parent object position
2 /* field number for spouse field */);
String maryName = FlatBufferHelper.getString(
flatBuffer,
johnPosition, // parent object position
2 /* field number for name field */);
The metadata in the FlatBuffer – 1610 in the example above – means “we only ever load the parts of the file that we need to read,” and “there is no need to deserialise the object tree before reading the fields.
This both reduces memory footprint, and speeds up access to data in the tree.
Xie also describes other FlatBuffers operations like data mutation, and after six months, he says, the transition to FlatBuffers in most Android clients is complete. ®
Biting the hand that feeds IT
