Making News Feed nearly 50% faster on iOS(code.facebook.com)
code.facebook.com
Making News Feed nearly 50% faster on iOS
https://code.facebook.com/posts/340384146140520/making-news-feed-nearly-50-faster-on-ios/
11 comments
> I really hope Apple will come up with a modern alternative to Core Data; it's neat and all, but it just doesn't feel like it's a good match for most situations.
This pretty much seems to be the aim of the (non-Apple) http://realm.io/
This pretty much seems to be the aim of the (non-Apple) http://realm.io/
CoreData is really meant for storing the entries that back your table view. Trying to use it as a universal data model seems unintended.
You might be right that it's best for that, but CoreData pre-dates table views by many years and has always been sold by Apple as a general store for object graphs.
Pre-dates table views? NSTableView dates to the 1990s. Core Data was introduced in 2005.
Core Data was based on the Enterprise Object Framework from NeXT.
Only loosely. And I don't believe EOF predates table views either.
Core Data lives in an unfortunate in between world. It's way too complicated for small amounts of data, and it's too slow for large amounts of data. It's useful if you have medium amounts of data, such that you can't reasonably keep everything in memory and rewrite everything to disk for serialization but don't have so much that you start to hit performance problems, but how often are you in a situation like that where you know your data won't grow larger?
I could have told them that. In my previous job I dealt with large JSON data as well but did not use Core Data but went with an immutable data layer as well. If you had to modify anything you had to make a new one. Core Data is fine for things that have to be modifiable and uploaded but if your requirement is mostly read only it's silly overhead.
I am pretty confident this is how Twitter manage data on their iOS app as well, and I'm also pretty sure they went through a similar "let's use a database/ORM, actually let's just write it to disk" process.
The three principles they listed for their model have served me well in apps I've written, especially the first (immutability). Most of the Apps I write rely on some kind of server data so it works really well. I'm writing a recipe book app as a learning project and I'm experimenting with just saving JSON to the App's document folder as a persistence layer.
Interesting article, but worth pointing out that core data is not an ORM, but an object graph with facilities for persistence.
You're right about this. My terminology was incorrect.
https://www.youtube.com/watch?v=XhXC4SKOGfQ is from the @scale conference last month that goes into more technical details about the architecture. Presented by the same person as the author of the article.
We hit similar problems with Core Data for http://clothapp.com and ended up migrating to Realm (http://realm.io) last month. Been pretty happy with it so far.
Is it me or does this article end right when some actual implementation details would have been interesting to see?
Yeah I would've loved a little more detail on how they architected the move to NSCoding / serialization straight to disk. There's a lot more ways to do this wrong than right from how open-ended a 'schema' like that is. Any speculations?
A while back, I came to the same conclusion as Facebook's iOS engineers for some apps that I work on. I based the model layer of the apps on Github's Mantle: https://github.com/Mantle/Mantle
Facebook's implementation probably ended up looking somewhat similar.
Facebook's implementation probably ended up looking somewhat similar.
It's pretty interesting to read about this stuff, I'm glad they're making progress. I hope they also work on the app accumulating data that never seems to get purged, or at least add a button to manually purge data.
What bothers me about this industry is that if you were to interview for an iOS position at a place like FB and suggest a KISS type solution, say using PONSOs for the data model, you would immediately be shown the door.
Since I had to look it up and I doubt I'm alone:
KISS - Keep it simple, stupid
PONSO - Plain ol NSObject
KISS - Keep it simple, stupid
PONSO - Plain ol NSObject
A great interviewer wouldn't be hung up on the "officially correct" way, but would instead expect the person to be aware of the different solutions and chat about the trade-offs.
A more likely case to the one you're describing would be someone suggesting implementing a search box with an O(N) search through an array (and offering no alternatives), and then being shown out the door.
A more likely case to the one you're describing would be someone suggesting implementing a search box with an O(N) search through an array (and offering no alternatives), and then being shown out the door.
As someone who has interviewed software engineers at a place like FB, I disagree. Sure, if you came in and stridently argued that this is the only possible solution, or if you couldn't explain the reasons you prefer it, or the tradeoffs involved, that's a bad sign.
Technical interviews are all about understanding how you approach problems, what kinds of solutions you're comfortable with, and how flexible you can be in the face of the types of constraints we encounter in our day to day jobs. So yes, someone who only knows one solution, and a non-standrd one at that, isn't likely to do well. But someone who knows the "rules" (aka the standard patterns) and can make a well-reasoned argument for breaking them in a specific situation is exactly the kind of engineer I'm looking for.
Technical interviews are all about understanding how you approach problems, what kinds of solutions you're comfortable with, and how flexible you can be in the face of the types of constraints we encounter in our day to day jobs. So yes, someone who only knows one solution, and a non-standrd one at that, isn't likely to do well. But someone who knows the "rules" (aka the standard patterns) and can make a well-reasoned argument for breaking them in a specific situation is exactly the kind of engineer I'm looking for.
You really wouldn't. The iOS dev community has no love for Core Data, despite it being the official "correct" way to implement data models.
The existence and popularity of libs like Realm is proof that not only is the community not married to the notion of Core Data, but there is a lot of noise being made in alternative data model layers.
If you are shown the door for suggesting a KISS solution and avoiding a buttload of dependencies and performance hits, consider it a bullet dodged, since odds are those people are terrible.
The existence and popularity of libs like Realm is proof that not only is the community not married to the notion of Core Data, but there is a lot of noise being made in alternative data model layers.
If you are shown the door for suggesting a KISS solution and avoiding a buttload of dependencies and performance hits, consider it a bullet dodged, since odds are those people are terrible.
Really, you get negative interview feedback for suggesting the use of a PONSO? As opposed to what, an NSDictionary/NSManagedObject/perhaps a struct?
No wonder I'm terrible at interviews.
No wonder I'm terrible at interviews.
You would? Why?
How long until they put messaging back within the fb app?
What's up with all the Facebook posts ending up at the top of HN lately?
Lots of hacking efforts = greater likelihood of those efforts capturing attention and showing up in places like the top of HN.
They're about interesting topics. Pretty simple.
I didn't say it was necessarily bad, just Facebook has been posting for years technical achievements and other interesting events related to their company. Occasionally (once a week or every couple weeks) these will make their way onto Hacker News, but in the last week, there have been multiple posts from facebook.com on the front page at the same time. I'm just curious as to why the sudden jump in posts from them on the front page.
This isn't a Facebook post, it's an iOS development post that happens to be about Facebook's app.
In my own anecdote, we had to show a list of autocompletion items - simple enough. Read XML, write a few hundred entries to a Core Data storage - and this list was relatively static, updated only once a week.
A week after release, we got crash reports - the XML read and store in CoreData was still running while people were already accessing the autocomplete list. It took (IIRC) 10 - 15 seconds to run (on an old iPhone 3GS), which was far too long from any standpoint.
So we just tossed CoreData, stored the list as a simple in-memory list, and made the autocomplete match search a very naive iteration-based search. Ten times faster, if not more.
TL;DR I would avoid CoreData, unless it's relatively static and non-time-critical data. And even then I'd look for alternatives first.