Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

engineering.fb.com

Post reply on HN
Print view View original

211–220 of 333 posts

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

#211

Post by joshspankit »

lord_braleigh wrote: post #203
nneonneo wrote: post #171

Earlier quoted context omitted.

The best part about this cycle is that developers can always point to some metric which shows improvement to justify their actions, resulting in an Escher-like loop where they think they’re always going up. These cycles pop up all the time in development as priorities shift (or as developers find more excuses to “fix” what isn’t broken). Real world coding always involves compromise - leadership is recognizing which c…

To be fair, small fast messenger 2020 is "better" (aka more features / millisecond of cold start) than small fast messenger 2016. The cycle doesn't always go up monotonically, even if developers pretend it does. But it is possible to go "full-circle" through the loop and wind up in a better place than you started, and it's even possible for each stage of the loop to be truly justified given product needs.

How much of that is simply improvement in processing speed of the device and/or better OS APIs?

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

#212

Post by on_and_off »

williamdclt wrote: post #67
on_and_off wrote: post #62

Earlier quoted context omitted.

-step 1 : write an app with a multiplatform framework. -step 2 : rewrite it in native so you greatly improve metrics while reducing code base size. Seems like a good way to achieve great improvements in your product

If the step 1 allows you to get your product out more quickly and that has enough business value, I don't see why not

That's fair and there is definitely a use case for these frameworks in order to quickly ship a product on several platforms.

There is also an inherent cost to rewriting all your codebase at once that should not be under estimated.

For something so big and integrated as messaging, I am not sure that this was a good match.

Admittedly turning messaging into a do all à la WeChat was very probably part of the initial plan.

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

#213

Post by hermitdev »

majormajor wrote: post #205
karatestomp wrote: post #72

Earlier quoted context omitted.

Which, for example, gets you more sway with your employer, personal "branding" value, and future income / ease of switching jobs: "I was instrumental in inventing React" versus "I was instrumental in realizing we didn't need to invent React"?

"I was instrumental in a major rewrite for [REASONS]" vs "We kept it the way it was because it was good enough and a rewrite would've improved [X] but hurt [Y]"

At a previous employer, I was dumped a client lib and server whose purpose was to maintain a data cache with realtime updates. It was fragile and slow as fuck.

When I got ahold of the source and started diving into it, discovered the client had 2 copies of the data, which was kept in memory. The server had 3 copies of the data in memory! Worse yet, the primary cache would be updated, then a multicast message was broadcast to update all the clients and the server's secondary and tertiary caches...thats right: the server would update the 2 other caches by broadcasting a multicast message, receiving it, then updating the other 2 after message receipt. A re-architecture was definitely in order. Took 3 months. Took another 3 months to get the interface to be backwards compatible with the original version.

Mind, the server was responsible for serving up relatively static market data for finance. But, considering we traded globally, we had +400 objects we cached, more than a few had 100ks of record. Memory usage for the server was many GB.

The rewrite involved moving to a single cache, instead of multiple for both client & server. It was also architected to handle large volumes of updates. Original implementation could even handle 100 updates per hour without bringing the server's and all clients to their knees. The write could handle +10k updates per second amd clients would barely notice a slowdown. Write locks were only held for a pointer swap. Memory usage for the server went down by close to 2/3. Client memory usage by 1/2.

During that time, also moved from static libs to dynamic on both Linux and Windows, so I could make nonbreaking changes without a firm wide recompile/relink, which typically took 3 days. HUGE productivity boost. A small bugfix didn't require a firmwide recompile/relock for the smallest bugfix.

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

#214

Post by jkmcf »

threeseed wrote: post #183
_bxg1 wrote: post #120

Earlier quoted context omitted.

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat To be fair, this is part of the problem ^

Just because there are features that you don't use doesn't make it a problem. In fact people who like stories and camera effects likely way outnumber the people that don't.

I interpreted “problem” as the bloat problem in a 1.7 mloc chat app.

Summarizing it as a chat app is probably the first miscommunication here.

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

#215

Post by BubRoss »

butz wrote: post #76

The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2

You do realize that you can have one code base and write in C++ right? You don't need a slow framework to have a UI run in multiple places.

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

#216

Post by jjn2009 »

bobbylarrybobby wrote: post #153
karatestomp wrote: post #81

Earlier quoted context omitted.

Well yeah, but first someone has to get the credit for creating some "high-productivity" hog of a framework to make it slow, then someone else can come tear all that crap out and claim they made it fast.

Why not be both people? "I made React and I made Messenger twice as fast [by ditching it]"

because that sentence can be read within the time span of human attention span and the problem with it easily identified.

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

#217

Post by Klonoar »

saagarjha wrote: post #187
Klonoar wrote: post #89

Earlier quoted context omitted.

Ah, you're correct - not sure why I thought otherwise, especially when I touch WKWebView pretty often.

Perhaps you confused it with JavaScriptCore?

Hmmm, possibly. Either way thanks for the catch!

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

#218

Post by monocularvision »

amarshall wrote: post #37
Scapeghost wrote: post #21

Earlier quoted context omitted.

I really wish iOS would allow you to select which contacts/photo album to give an app access to, instead of all hundreds/thousands of them.

For photos, I wish iOS would not require a permission at all in the case where I just want it to open an OS-controlled file picker and then give the app the one photo, akin to copy-pasting it. No reason to give access to every photo when only N are picked.

https://developer.apple.com/documentation/uikit/uiimagepicke...

iOS 2.0+

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

#219

Post by fao_ »

butz wrote: post #76

The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2

From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000."

Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app.

See also: this other comment - https://news.ycombinator.com/item?id=22468036

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

#220

Post by pests »

moron4hire wrote: post #95
aldanor wrote: 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 have a set of code I use for my VR projects that I've been iterating on over the last five or so years. It includes a ton of not-VR stuff, too, just stuff that I tend to include in my projects. (aside: and I'm not trying to make it a "framework". It's just my own code and it's only publicly available in the sense that I don't charge for it, don't want to waste a private Github repo on it, and won't stop anyone from…

For what it's worth, GitHub private repos are now free so you don't have to sorry about wasting one.
Post reply on HN