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

  • Google has more reasons why it doesn't like antitrust law that affects Google
    It'll ruin Gmail, claims web ads giant

    Google has a fresh list of reasons why it opposes tech antitrust legislation making its way through Congress but, like others who've expressed discontent, the ad giant's complaints leave out mention of portions of the proposed law that address said gripes.

    The law bill in question is S.2992, the Senate version of the American Innovation and Choice Online Act (AICOA), which is closer than ever to getting votes in the House and Senate, which could see it advanced to President Biden's desk.

    AICOA prohibits tech companies above a certain size from favoring their own products and services over their competitors. It applies to businesses considered "critical trading partners," meaning the company controls access to a platform through which business users reach their customers. Google, Apple, Amazon, and Meta in one way or another seemingly fall under the scope of this US legislation. 

    Continue reading
  • Makers of ad blockers and browser privacy extensions fear the end is near
    Overhaul of Chrome add-ons set for January, Google says it's for all our own good

    Special report Seven months from now, assuming all goes as planned, Google Chrome will drop support for its legacy extension platform, known as Manifest v2 (Mv2). This is significant if you use a browser extension to, for instance, filter out certain kinds of content and safeguard your privacy.

    Google's Chrome Web Store is supposed to stop accepting Mv2 extension submissions sometime this month. As of January 2023, Chrome will stop running extensions created using Mv2, with limited exceptions for enterprise versions of Chrome operating under corporate policy. And by June 2023, even enterprise versions of Chrome will prevent Mv2 extensions from running.

    The anticipated result will be fewer extensions and less innovation, according to several extension developers.

    Continue reading
  • I was fired for blowing the whistle on cult's status in Google unit, says contractor
    The internet giant, a doomsday religious sect, and a lawsuit in Silicon Valley

    A former Google video producer has sued the internet giant alleging he was unfairly fired for blowing the whistle on a religious sect that had all but taken over his business unit. 

    The lawsuit demands a jury trial and financial restitution for "religious discrimination, wrongful termination, retaliation and related causes of action." It alleges Peter Lubbers, director of the Google Developer Studio (GDS) film group in which 34-year-old plaintiff Kevin Lloyd worked, is not only a member of The Fellowship of Friends, the exec was influential in growing the studio into a team that, in essence, funneled money back to the fellowship.

    In his complaint [PDF], filed in a California Superior Court in Silicon Valley, Lloyd lays down a case that he was fired for expressing concerns over the fellowship's influence at Google, specifically in the GDS. When these concerns were reported to a manager, Lloyd was told to drop the issue or risk losing his job, it is claimed. 

    Continue reading

Biting the hand that feeds IT © 1998–2022