4 ms·

I'd like to see the same speed measurements done for mobile. A 64-bit Linux desktop isn't representative of the #1 use case for SQLite as a mobile database repl

I'd like to see the same speed measurements done for mobile. A 64-bit Linux desktop isn't representative of the #1 use case for SQLite as a mobile database replacement for Core Data.

thomaslutz 11y ago
Why should it not be similar faster on mobile?
- gburt 11y ago
  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.
  - vvanders 11y ago
    Even moreso, different cache sizes. Some object that might fit nicely in a 4kB cache might get destroyed with a 1kB cache.
- Zergy 11y ago
  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.
- em3rgent0rdr 11y ago
  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.
  - pcwalton 11y ago
    Also multicore memory hierarchies are very different on ARM -- e.g. atomics are much more expensive there in my experience.
DrJokepu 11y ago
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?
- kbenson 11y ago
  I imagine it's showing in benchmarks that approximate mobile usage might actually influence that timeline slightly.
- matsur 11y ago
  Building and linking your own sqlite.c is completely feasible. (We do it).
  - DrJokepu 11y ago
    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?
toyg 11y ago
sqlite existed before iOS and I doubt that platform is its "#1 use case". Sqlite powers tons of apps on many different platforms.
- kbenson 11y ago
  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.
- simonh 11y ago
  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.
  - toyg 11y ago
    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.
developernotes 11y ago
>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 https://github.com/sqlcipher/SQLCipherSpeed

I'd like to see the same speed measurements done for mobile. A 64-bit Linux desktop isn't representative of the #1 use case for SQLite as a mobile database replacement for Core Data.

thomaslutz 11y ago

Why should it not be similar faster on mobile?

gburt 11y ago
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.
- vvanders 11y ago
  Even moreso, different cache sizes. Some object that might fit nicely in a 4kB cache might get destroyed with a 1kB cache.
Zergy 11y ago
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.
em3rgent0rdr 11y ago
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.
- pcwalton 11y ago
  Also multicore memory hierarchies are very different on ARM -- e.g. atomics are much more expensive there in my experience.

DrJokepu 11y ago

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?

kbenson 11y ago
I imagine it's showing in benchmarks that approximate mobile usage might actually influence that timeline slightly.
matsur 11y ago
Building and linking your own sqlite.c is completely feasible. (We do it).
- DrJokepu 11y ago
  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?

toyg 11y ago

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

kbenson 11y ago
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.
simonh 11y ago
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.
- toyg 11y ago
  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.

developernotes 11y ago

>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 https://github.com/sqlcipher/SQLCipherSpeed