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…
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
131–140 of 333 posts
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#132Considering 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
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#133Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#134So, 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.
> 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
#135I 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?
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#136Not 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.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#137Considering 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
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#138Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#139It'll suck for the SEO team at LightSpeed point of sale company. FB named a open source project the same name as a company.
Re: LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app
#140So, 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…
Having a GUI doesn't justify 1 million+ LOCs, but just for a sanity check, pgAdmin 4 has ~260k LOCs, without counting its dependencies.