Michael TsaiVerified account

@mjtsai @drewmccormack a generalised framework can never be as fast as specialised because the general case cannot make certain assumptions.

@milend @mjtsai Only in theory. It assumes you have developers capable of it, and good caching is not easy. You pay a price too: rigidity.

@drewmccormack @mjtsai agreed about time / resources required. It's very much a question of deciding whether the pros outweigh the cons.

@milend @mjtsai I would even argue that SQLite is specialized for high perf disk access. CD is specialized to make high perf apps (disk+RAM)

@drewmccormack It’s possibly convenient, but not high perf, to bring all objects into RAM before operating on them.

@mjtsai It's always much faster operating on in-memory objects than on disk objects. In many cases it's a big perf win.

@mjtsai Quick scan shows Calendar, Contacts, Notes, iBooks. More important, 3rd party apps Pixelmator, Tokens, Transmit, Yojimbo.

@drewmccormack Notes and iBooks don’t use it for syncing, either. Nor for storing large amounts of data. No iWork or iLife apps (AFAIK).

@mjtsai Won't argue with you on iCloud sync: it's rubbish. iWork etc are pretty old. Think it is all still XML.

@drewmccormack You think that, absent the history, Core Data would make a better word processing/spreadsheet document format than XML?

@mjtsai Probably. Don't know what they do on iOS. I guess they split the XML into multiple files for partial loading. Ie, primitive DB.

@drewmccormack @mjtsai FYI, the text of Moby Dick is 1.2MB uncompressed, so that's 10 Moby Dick's for 1 full screen retina iPad image.

@mpweiher Text is small, structure much bigger. Doubt a big keynote XML could load into memory on iOS. Images are easy. Mostly stay on disk.

@mjtsai @drewmccormack I think it's quite simple - any non trivial app can exploit its unique requirements to provide better performance.