Live data from Hacker News

LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

engineering.fb.com

131–140 of 333 posts

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#131

From https://engineering.fb.com/data-infrastructure/messenger/ : Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used qui…

A similar philosophy can often be applied to the web

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#132
post #7

Considering that they were shipping 18,000 classes in their iOS app back in 2015, a quarter the size of their 2019 app has to be still unreasonably massive. https://gist.github.com/quellish/473f513fbd1310233a8e

The number of classes isn't necessarily indicative of the size or complexity of an app.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#134
post #98
post #85

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment: - NumPy is 360K lines mostly C - Postgres is around 2.1M of C - Go 1.13 is around 1.5M of Go code - Rust 1.37 is around 1.2M of Rust code iirc - core llvm is around 3M of C++ iirc ... A chat app is 1.7M. A chat app... Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've…

I'm fairly certain that they also included third-party libraries in that 1.7M.

It seems you are correct:

> We also used quite a few of the OS libraries, including the JSON processing library, rather than building and storing our own libraries in the codebase.

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#135

I still aren't 100% sure what they're using Sqlite for? Are they storing templates as blobs? Are the storing template logic in the table? How did that make things faster? Anybody who has more detail care to explain?

It sounds like the entire client-side state of their app is in SQLite

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#136
post #18

Not sure how much impact this will have, most of the people I know and have discussed this with fall into two camps: people who use FB a lot an will put up with a bad mobile client, and people who don't want FB on their phone, ever. I have to go years back to think of someone who told me they just couldn't take the bad UX of the clients so they deleted it.

For a while, before it really started to bloat, FB Messenger was the slickest, most well-rounded, most enjoyable messaging client I could find, and had the advantage that all of your friends were already on it. The bloating from Stories and everything happened to coincide with my ejection of all things Facebook from my life, but Messenger was a genuinely good product at one point. Sounds like it may be returning to that (though unfortunately that ship has sailed for other reasons).

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#137
post #7

Considering that they were shipping 18,000 classes in their iOS app back in 2015, a quarter the size of their 2019 app has to be still unreasonably massive. https://gist.github.com/quellish/473f513fbd1310233a8e

That's Facebook proper not the Messenger app

Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app

#140
post #85

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment: - NumPy is 360K lines mostly C - Postgres is around 2.1M of C - Go 1.13 is around 1.5M of Go code - Rust 1.37 is around 1.2M of Rust code iirc - core llvm is around 3M of C++ iirc ... A chat app is 1.7M. A chat app... Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've…

All these programs have textual interfaces only (as far as I know).

Having a GUI doesn't justify 1 million+ LOCs, but just for a sanity check, pgAdmin 4 has ~260k LOCs, without counting its dependencies.

Post reply on HN