I've never worked with Core Data, but I assume it always uses the SQLite version that ships with iOS (as opposed to a version you ship with your app), so that means that you wouldn't see these improvements on iOS for at least a year or so anyway, or am I wrong about this?

Building and linking your own sqlite.c is completely feasible. (We do it).

Yes, that's something that I do as well, but will Core Data pick it up, or will it use the one that ships with the system?

I imagine it's showing in benchmarks that approximate mobile usage might actually influence that timeline slightly.

sqlite existed before iOS and I doubt that platform is its "#1 use case". Sqlite powers tons of apps on many different platforms.

The post you're replying to doesn't mention iOS, just mobile (though it may have been edited). Anyway SQLite is heavily used in Android and well, and other mobile platforms going back to all but the early versions of Symbian even. It's been the standard for address book, calendar, settings, to-do apps, etc for over a decade. A typical smartphone probably contains around half a dozen SQLite DBs right out of the box, which means the building I'm in probably houses several thousand of them. The total number of DBs in the world must be in the tens of billions, just from mobile devices.

parent says "Core Data", hence iOS. iOS alone is certainly not the #1 case, since Android has bigger numbers as you know. I just thought it smacked a bit of "Apple bubble", that's all.

Actually, I wouldn't be surprised at all, given that it seems to be the canonical on-disk data store for both Android and iOS. Whether you want to measure total uses by developers, the developers themselves, the users using it, the apps using it, the size data stored, I imagine mobile use probably swamps everything else.

For example, I probably have 20-30 sqlite using apps on my phone, if not more. And I wiped it clean when I got a new phone a few months back and have been fairly hesitant to add apps I haven't found proven use for.

>I'd like to see the same speed measurements done for mobile.

While not exactly what you are looking for I can understand the sentiment. SQLCipher provides a project to time the performance of queries when run against standard SQLite vs. SQLCipher on iOS.

https://github.com/sqlcipher/SQLCipherSpeed

Why should it not be similar faster on mobile?

No only different instruction set, but probably drastically different cache hierarchy and branch predictors. The tool cachegrind which they are using is simulating a program's effect on the cache and branch predictor, which will likely both be dramatically smaller in embedded devices vs modern server CPUs, so the results may be very misleading to real world applications for sqite.

Also multicore memory hierarchies are very different on ARM -- e.g. atomics are much more expensive there in my experience.

Different instruction set. The release notification isn't very clear about what optimizations took place. It is quite possible that it will not be the same result on a different architecture.

Even moreso, different cache sizes. Some object that might fit nicely in a 4kB cache might get destroyed with a 1kB cache.

He never said it shouldn't, just that he would be interested in seeing the numbers. I would be too since they would be more relevant to my use case.