@mjtsai Not really. Some teams in Apple are surprisingly ignorant of Apple's own tech. What do they use instead? XML?
Rest my case.
-
-
@drewmccormack Article says that you should use Core Data because Apple uses it for apps, and Apple knows best. But where are said apps?0 replies 0 retweets 0 likes -
@mjtsai@drewmccormack a generalised framework can never be as fast as specialised because the general case cannot make certain assumptions.0 replies 0 retweets 0 likes -
@drewmccormack@mjtsai agreed about time / resources required. It's very much a question of deciding whether the pros outweigh the cons.0 replies 0 retweets 0 likes -
@drewmccormack It’s possibly convenient, but not high perf, to bring all objects into RAM before operating on them.0 replies 0 retweets 0 likes -
@mjtsai It's always much faster operating on in-memory objects than on disk objects. In many cases it's a big perf win.0 replies 0 retweets 0 likes -
@drewmccormack And an SQLite index on disk can be way faster than Core Data’s in-memory predicate filtering.0 replies 0 retweets 0 likes -
@mjtsai@drewmccormack Core Data predicates are translated to SQL queries.0 replies 0 retweets 0 likes
@atomicbird Right. You have to bring the objects into memory to modify them; then, until you save, you get slow in-memory filtering.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Drew McCormack
Michael Tsai
Milen Dzhumerov
Tom Harrington