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.

Facebook social graph

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.

Flatbuffer storage schema

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. ®


Other stories you might like

  • GPL legal battle: Vizio told by judge it will have to answer breach-of-contract claims
    Fine-print crucially deemed contractual agreement as well as copyright license in smartTV source-code case

    The Software Freedom Conservancy (SFC) has won a significant legal victory in its ongoing effort to force Vizio to publish the source code of its SmartCast TV software, which is said to contain GPLv2 and LGPLv2.1 copyleft-licensed components.

    SFC sued Vizio, claiming it was in breach of contract by failing to obey the terms of the GPLv2 and LGPLv2.1 licenses that require source code to be made public when certain conditions are met, and sought declaratory relief on behalf of Vizio TV owners. SFC wanted its breach-of-contract arguments to be heard by the Orange County Superior Court in California, though Vizio kicked the matter up to the district court level in central California where it hoped to avoid the contract issue and defend its corner using just federal copyright law.

    On Friday, Federal District Judge Josephine Staton sided with SFC and granted its motion to send its lawsuit back to superior court. To do so, Judge Staton had to decide whether or not the federal Copyright Act preempted the SFC's breach-of-contract allegations; in the end, she decided it didn't.

    Continue reading
  • US brings first-of-its-kind criminal charges of Bitcoin-based sanctions-busting
    Citizen allegedly moved $10m-plus in BTC into banned nation

    US prosecutors have accused an American citizen of illegally funneling more than $10 million in Bitcoin into an economically sanctioned country.

    It's said the resulting criminal charges of sanctions busting through the use of cryptocurrency are the first of their kind to be brought in the US.

    Under the United States' International Emergency Economic Powers Act (IEEA), it is illegal for a citizen or institution within the US to transfer funds, directly or indirectly, to a sanctioned country, such as Iran, Cuba, North Korea, or Russia. If there is evidence the IEEA was willfully violated, a criminal case should follow. If an individual or financial exchange was unwittingly involved in evading sanctions, they may be subject to civil action. 

    Continue reading
  • Meta hires network chip guru from Intel: What does this mean for future silicon?
    Why be a customer when you can develop your own custom semiconductors

    Analysis Here's something that should raise eyebrows in the datacenter world: Facebook parent company Meta has hired a veteran networking chip engineer from Intel to lead silicon design efforts in the internet giant's infrastructure hardware engineering group.

    Jon Dama started as director of silicon in May for Meta's infrastructure hardware group, a role that has him "responsible for several design teams innovating the datacenter for scale," according to his LinkedIn profile. In a blurb, Dama indicated that a team is already in place at Meta, and he hopes to "scale the next several doublings of data processing" with them.

    Though we couldn't confirm it, we think it's likely that Dama is reporting to Alexis Bjorlin, Meta's vice president of infrastructure hardware who previously worked with Dama when she was general manager of Intel's Connectivity group before serving a two-year stint at Broadcom.

    Continue reading

Biting the hand that feeds IT © 1998–2022