Skip to main content

FlatBuffers instead of JSON (or Protocol Buffers)

FlatBuffers is an efficient cross platform serialization library for C++, Java, C#, Go, Python and JavaScript (C, PHP & Ruby in progress). It was originally created at Google for game development and other performance-critical applications.

Why use FlatBuffers?

  • Access to serialized data without parsing/unpacking - What sets FlatBuffers apart is that it represents hierarchical data in a flat binary buffer in such a way that it can still be accessed directly without parsing/unpacking, while also still supporting data structure evolution (forwards/backwards compatibility).
  • Memory efficiency and speed - The only memory needed to access your data is that of the buffer. It requires 0 additional allocations (in C++, other languages may vary). FlatBuffers is also very suitable for use with mmap (or streaming), requiring only part of the buffer to be in memory. Access is close to the speed of raw struct access with only one extra indirection (a kind of vtable) to allow for format evolution and optional fields. It is aimed at projects where spending time and space (many memory allocations) to be able to access or construct serialized data is undesirable, such as in games or any other performance sensitive applications. See the benchmarks for details.
  • Flexible - Optional fields means not only do you get great forwards and backwards compatibility (increasingly important for long-lived games: don't have to update all data with each new version!). It also means you have a lot of choice in what data you write and what data you don't, and how you design data structures.
  • Tiny code footprint - Small amounts of generated code, and just a single small header as the minimum dependency, which is very easy to integrate. Again, see the benchmark section for details.
  • Strongly typed - Errors happen at compile time rather than manually having to write repetitive and error prone run-time checks. Useful code can be generated for you.
  • Convenient to use - Generated C++ code allows for terse access & construction code. Then there's optional functionality for parsing schemas and JSON-like text representations at runtime efficiently if needed (faster and more memory efficient than other JSON parsers). Java and Go code supports object-reuse. C# has efficient struct based accessors.
  • Cross platform code with no dependencies - C++ code will work with any recent gcc/clang and VS2010. Comes with build files for the tests & samples (Android .mk files, and cmake for all other platforms).
Why not use Protocol Buffers, or .. ?

Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has neither optional text import/export nor schema language features like unions.


FlatBuffers on GitHub

Improving Facebook's performance on Android with FlatBuffers
FlatBuffers is a data format that removes the need for data transformation between storage and the UI. In adopting it, we have also driven additional architectural improvements in our app like Flat Models. The mutation extensions that we built on top of FlatBuffers allow us to track server data, mutations, and local state all in a single structure, which has allowed us to simplify our data model and expose a unified API to our UI components.

In last six months, we have transitioned most of Facebook on Android to use FlatBuffers as the storage format. Some performance improvement numbers include:


  • Story load time from disk cache is reduced from 35 ms to 4 ms per story.
  • Transient memory allocations are reduced by 75 percent.
  • Cold start time is improved by 10-15 percent.
  • We have reduced storage size by 15 percent.

FlatBuffersSwift on GitHub
Infrastructure for FlatBuffers, contains a reader and a builder

Comments

Most Favorite Posts

TechLead: React Native vs Flutter vs WebView - Hybrid Mobile App Development for 2018

Topics covered: Xamarin, Cordova, Flutter, Titanium, React Native, Flutter React Native Web Views Native Development: iOS and Android Types of apps: Fully native high interactivity expensive: iOS and Android high interactivity, personalization, performance worth for top 50 apps less and less apps are installed you need to shine to be discovered user picks only best app among similar featured apps Hybrid Technologies Xamarin, Cordova, Flutter, Titanium, React Native, Flutter Be aware of the maturity lock-in effect infrastructure and tooling required might get worst of both world should be incrementable updatable check where it makes sense WebViews only Native App shells: Amazon App, Apple App Store, WeChat Mainly for smaller companies Trending on Google Links: AirBnB is sunsetting its React Native development What’s Next for Mobile at Airbnb Server-Driven Rendering Even though we’re not using React Native, we still see the val...

Firebase realtime database stability - and monitoring

Firebase SLA Firebase will use commercially reasonable efforts to make Firebase available with a Monthly Uptime Percentage (defined below) of at least 99.95%, in each case during any monthly billing cycle (the "Service Commitment"). Firebase SLA Service Level Agreement for Hosting and Realtime Database Firebase Status Page Why Firebase sucks In the 3 years since starting to use Firebase we’ve suffered from so many outages I’ve literally lost count. @ Medium.com Status History Overview Statusgator Does anyone has real-life experience with the stability of Firebase or Firestore? Please leave a comment! We heared that Firestore is much more stable than Firebase which usage for new project is discouraged...

Backend-driven native UIs

Backend-drive native UIs John Sundell  Slide Share Using Back-End Design to Create Customizable Front-End Mobile Experiences By controlling the front end of mobile apps from the back end we can build customized experiences at runtime, creating cleaner interfaces and reducing load times. Nithin Rao UX Magazine The Hub Framework Welcome to the Hub Framework - a toolkit for building native, component-driven UIs on iOS ( no Android support released yet ). It is designed to enable teams of any size to quickly build, tweak and ship new UI features, in either new or existing apps. It also makes it easy to build backend-driven UIs. The Hub Framework has two core concepts - Components & Content Operations. Spotify LeeGo: Build UI without UIView LeeGo is a lightweight Swift framework that helps you decouple & modularise your UI component into small pieces of LEGO style's bricks, to make UI development declarative, configurable and highly reusable. Wang Shen...

Validity Time Auto-Renewables in Sandbox

The subscription durations, sandbox durations and incentive durations of auto-renewables. Hint: In Sandbox the validity time differs from live environment!!! Durations Sandbox Duration Incentive Durations (optional) 7 days 3 minutes 7 days 1 month 5 minutes 7 days, 1 month 2 months 10 minutes 7 days, 1 month 3 months 15 minutes 1 month 6 months 30 minutes 1 month, 2 months 1 year 1 hour 1 month, 2 months, 3 months After 6 extensions the abo is cancelled automatically in the sandbox environment.

Understanding Automatic Reference Counting in Objective-C

Automatic Reference Counting (ARC) largely removes the burden of manual memory management, not to mention the chore of tracking down bugs caused by leaking or over-released objects! Despite its awesomeness, ARC does not let you ignore memory management altogether. This post covers the following key aspects of ARC to help you get up and running quickly. Reference Counted Memory: Quick Revision How Automatic Reference Counting Works Enabling ARC in Your Project New Rules Enforced by ARC ARC Qualifiers – Declared Properties ARC Qualifiers – Regular Variables Migrating Existing Projects to ARC Including Code that is not ARC Compliant Should I Use ARC? The Long Weekend Website

Dark Theme (Dark Mode) in Android WebViews, WKWebViews and CSS

So your apps just implemented a shiny new dark theme and it’s looking 👌 There are lots of benefits to having a dark theme in your application, and having it consistent throughout your application allows for a great user experience. But what happens when the the user runs into a WebView in your app? Support: if (WebViewFeature.isFeatureSupported(WebViewFeature.FORCE_DARK)) { ... } Set: WebSettingsCompat.setForceDark(webView.settings, WebSettingsCompat.FORCE_DARK_ON) Current setting: val forceDarkMode = WebSettingsCompat.getForceDark(webView.settings) Joe Birch Assuming your question is asking how to change the colors of the HTML content you are displaying in a WKWebView based on whether light or dark mode is in effect, there is nothing you do in your app's code. All changes need to be in the CSS being used by your HTML content. CSS dark mode via :root variables, explicit colors and @media query: :root {     color-scheme: light dark;      ...

JSLint

Many JavaScript implementations do not warn against questionable coding practices. Yes, that's nice for the site that "works best with Internet Explorer" (designed with templates, scripted with snippets copied from forums). But it's a nightmare when you actually want to write quality, maintainable code. That's where JavaScript Lint comes in. With JavaScript Lint, you can check all your JavaScript source code for common mistakes without actually running the script or opening the web page. JavaScript Lint holds an advantage over competing lints because it is based on the JavaScript engine for the Firefox browser. This provides a robust framework that can not only check JavaScript syntax but also examine the coding techniques used in the script and warn against questionable practices. JavaScript Lint Online Form