fbpx
Objectively Swifter: How Swift & C superpowers outperform Objective-C in ObjectBox Swift 0.8

Objectively Swifter: How Swift & C superpowers outperform Objective-C in ObjectBox Swift 0.8

While we’ve been optimizing ObjectBox for speed right from the beginning, making it the fastest database around, the fastest library in the world is useless if its interface to your language isn’t optimized for that language’s strengths and weaknesses. The 0.8.0 release of ObjectBox for Swift gives you a nearly 70% performance boost out of the box by improving the way we integrate with Swift:

How did we Achieve this Speed-Up?

When we created ObjectBox’s Swift binding, we did not have our C API yet. So, to bridge between the C++ database core and Swift, we implemented a number of classes using Objective-C++. Objective-C++ is neat: it looks to Swift like Objective-C (so like a Swift class), but will happily call into C++ code.

Objective-C is also a very different language from Swift, and particularly generics and structs don’t have a direct equivalent in Objective-C. So when we realized that many reactive frameworks in Swift were built around structs, we decided to change gears. We rewrote a number of core Objective-C classes in the Swift binding as Swift classes on top of the C API that we now use in all our newer language bindings, eliminating a lot of Objective-C’s dynamic dispatch, and generally improving upon algorithms here and there.

The main goal was to give our users struct support and lay the groundwork for taking advantage of Swift 5.1’s upcoming UTF8 strings by eliminating use of the UTF16-based NSString. We also wanted to bring ObjectBox’s Objective-C-beholden error handling in line with Swift conventions. So we expected modest speed-ups here and there, but a speed increase this noticeable even before Swift 5.1 was a pleasant surprise, and we wanted to get these improvements into our users’ hands as quickly as possible.

Using structs with ObjectBox

One rather unique aspect of Swift compared to other languages is how Swift defines the term struct as value type and class as reference type. That makes structs incredibly handy for cases where you want to guarantee an object can never change.

Thread-safety, for instance: if you know an object is unchangeable, there is no chance of race conditions while editing. You need no locks, no copies; your threads can all safely operate on the same memory.

However, when you put an object into your ObjectBox database, put(_:)updates the object’s id property to establish the association between the database entry and your object in memory. ObjectBox can’t do that with unchangeable structs, so we needed to make a slight adjustment to ObjectBox’s usual simple put(_:) flow:

Missed the difference? It’s tiny: You use put(struct:) instead of the regular put(_:). put(struct:) will create a copy of the struct you gave it with the ID changed to whatever ID the object was assigned in the database (the copy is what we store in savedUser in the above example).

So, what if you want to make changes? The way you change immutable structs is to make a copy with the one thing you wanted to change set to a different value. So while you could save it to the database using put(struct:), you already made a copy of the object, and it will not change after being saved, because it already has an ID. Won’t that second copy be wasteful?

That’s why Box now also offers putImmutable(_:). If you know that your object has already been saved, and you don’t need a copy. Just call putImmutable(_:). instead of put(struct:).

This will return the ID for your convenience, but you can always ignore it, if you do not need it.

What else has changed?

While we’re always improving things under the hood, not much should change for your existing ObjectBox code. Apart from the new ObjectBoxError enum replacing the janky old Objective-C-style OBXError... classes, your existing code should just compile. All the changes are in the generated code.

Go give it a try, and let us know how we’re doing.

Go, ObjectBox Golang!

Go, ObjectBox Golang!

Today, we are bringing the power of ObjectBox to Go. Whatever solution you are building, be it a web service, an IoT/IIoT solution, or any data-driven application, you will benefit from the efficiency and speed of ObjectBox (see benchmarks below). Let us know what you think!

Let’s look at some code, and see how ObjectBox persists Go structs (objects):

The ObjectBox Go API allows you to create data-driven cross-platform apps. ObjectBox supports x64 and 32 bit ARM (ARMv6 and ARMv7) CPUs, enabling you to benefit from a super-fast scalable database on IoT devices, industrial edge gateways or, for example, the Raspberry Pi family (from the minimalistic Pi Zero to the high-spec Pi 3B+). At the same time, you can now target desktop and server apps running on Linux, MacOS, or Windows using Go.

How to get started

To get started, please have a look at the ObjectBox Go docs. Here’s the TL;DR version for your bash:

This will clone the repository to your GOPATH, download the objectbox-c library and install the ObjectBox code generator.

At this point you can start using ObjectBox in your project – just define a struct you want to persist, add  //go:generate objectbox-gogen  comment in the same file and run go generate ./… on your project. See Getting started for more details.

Performance benchmarks

We have done some quick CRUD performance tests to give you an impression about the speed ObjectBox provides. On a i7-8850H CPU, ObjectBox consistently processes over 1.5 million CRUD operations per second with 4.4 million object reads per second:

The sources for the performance tests are part of the GitHub repository.

To put these numbers into perspective, we also did a comparison using an edge computing platform and two leading NoSQL databases. We won’t spill the names and final numbers just yet, as we are going to release all the details very soon. 😉

Disclaimer: ObjectBox was the only database running in embedded mode, which is not supported by the others in this setup. Obviously this can have a significant impact on performance. On the other hand, this is the most resource friendly mode of operation (RAM and CPU), which might be very relevant if you target restricted ARM32 devices.

Your feedback

This is the first public version of ObjectBox for Go and we are more than excited to get your feedback on it. We have prepared a short questionnaire for you, which should only take 1-2 minutes. Your feedback is extremely valuable to make ObjectBox a fun tool to use.

Future work

While this initial release covers all basic features, the native core of ObjectBox offers much more than what is currently exposed to Go. For example, a complete set of query conditions and relations between objects. Also, we will introduce a client/server operation mode. This will allow ObjectBox to run in Containers (e.g. Docker) and in classic server setups. As a major theme, the ObjectBox team is also working on data synchronization across devices. This keeps edge devices and gateways “in-sync”. Sync also enables seamless integration with mobile apps (Android and iOS) pushing relevant data to mobile clients and back.  Of course sync will also be available for Go. You can sign up here for updates on sync.

 

Let’s dive into the iOS World

Let’s dive into the iOS World

Two days ago, we attended the Swift Lighting Talks Meetup in Munich for the very first time. We had beer, pizza and listened to Sebastian Sellmeier’s presentation on making programming accessible and Denis Grebennicov’s presentation on the process of developing a Document Scanner app. It was fun and very instructive, thanks!

We also gave a 15 minute sneak peek talk about our ObjectBox iOS binding. Markus covered the basics of ObjectBox before sharing how we managed to overcome iOS constraints in our APIs. Finally, he disclosed the first (early) performance benchmarks on iOS, which we think are quite encouraging…

Check out the full talk in the video below.

In case you want to learn more about ObjectBox on iOS, sign up here for news and Early Access.
Special thanks to Stefan Mayer-PoppThe Munich iOS Developers Meetup for organizing this event and to Mayflower for hosting it.

 

We officially released our YouTube channel, we will post videos about ObjectBox and Tech in general. Subscribe to stay tuned.

 

ObjectBox 0.9.10 – getting closer to 1.0

ObjectBox 0.9.10 – getting closer to 1.0

ObjectBox 0.9.10 - getting closer to 1.0

Do you know our new super fast mobile database ObjectBox yet? With versions 0.9.9 and the just released 0.9.10, ObjectBox made great progress to stabilize features for the 1.0 release. With an increasing number of apps using ObjectBox, we were able to spot and fix some less obvious issues. We believe that ObjectBox 0.9.10 is the most stable release ever. If you did not dare to check out the beta version yet: now is a good time to have a closer look.

(more…)

Mobile Database Comparison: SQLite and SQLite alternatives compared in a handy matrix

Mobile Database Comparison: SQLite and SQLite alternatives compared in a handy matrix

Mobile databases: SQLite and SQLite alternatives for Android and iOS

Updated comparison

Note: This is an updated version of an earlier Mobile Database Comparison.

What is a mobile database?

While Wikipedia defines a mobile database as “either a stationary database that can be connected to by a mobile computing device […] over a mobile network, or a database which is actually stored by the mobile device,” we solely refer to databases that run on the mobile device itself (on-device).

What are the advantages and disadvantages of working with SQLite?

SQLite is easily the most established mobile database, probably the only “established” mobile database. SQLite has been around since the year 2000 and is embedded with iOS and Android since the beginning. SQLite is a relational database.

advantages

disadvantages

  • Toolchain, e.g. DB browser
  • No dependencies; included with Android and iOS
  • Developers can exactly define the data schema they want
  • Developers have full control, e.g. they can do handwritten SQL queries
  • SQL is a powerful and established query language, and SQLite supports most of it
  • Debuggable data: developers can grab the database file and analyze it
  • Rock-solid, widely used technology, established since the year 2000

  • Using SQLite means a lot of boilerplate code and thus inefficiencies (also in the long run with the app maintenance)
  • 1 MB BLOB Limitation on Android
  • No compile time checks (e.g. SQL queries)
  • SQLite performance is unreliable
  • SQL is another language to master
  • SQL queries can get long and complicated
  • Testability (how to mock a database?)
  • Especially when database views are involved, maintainability may be poor with SQLite

What are SQLite alternatives?

There are plenty of alternatives to working with SQLite directly. If you simply want to avoid writing lots of SQL and boilerplate code, you can use an object abstraction on top of SQLite. This abstraction is usually an ORM (object/relational mapper), e.g. greenDAO.

However, if you rather seek a replacement for SQLite completely, there are also a few alternative databases: Couchbase Lite, Interbase, LevelDB, Oracle Berkeley DB (formerly Oracle’s mobile database was “Oracle Database Lite”), Realm, SnappyDB, SQL Anywhere, and UnQLite.

Obviously, if your also looking for alternatives that are not on-device mobile databases, there are a lot of cloud / server options out there that you can use as a replacement like e.g. Firebase. Generally speaking, with these your app will not be (fully) offline-capable, costs on the serverside will go up, and they may also be rather slow in execution.

To give you an overview, we have compiled a small comparison table:

NameAndroid / iOSType of data storedSync CentralSync P2PData level encryptionLicense / business modelShort descriptionMinimum Footprint sizeCompany
Couchbase Lite, now Couchbase Mobile
Android / iOSJSON Documents / NoSQL db YesYesDatabase encryption with SQLCipher (256-bit AES)Apache 2.0Embedded / portable db with P2P and central synchronization (sync) support. Secure SSL.Couchbase
ForestDB
Android / iOSKey-value pairs / NoSQL dbNoNoNoApache 2.0Portable lightweight key-value store, NoSQL database.
InterBase ToGo / IBLite
Android / iOSRelationalNoNo256bit AES strength encryptionProprietaryEmbeddable SQL database.400 KBEmbarcadero
LevelDB
Android / iOSKey-value pairs / NoSQL dbNoNoNoNew BSDPortable lightweight key-value store, NoSQL db, doesn't support indexes, very fast for some use cases; earlier available enchmarks from 2011 have been removed unfortunately.350kBLevelDB Team
Oracle Database Lite
Android / iOSRelational and Key-Value-StoreWith Oracle Mobile ServerWith Oracle Mobile Server128-bit AES Standard encryptionProprietaryEmbedded / portable db with P2P and central sync support as well as support for sync with SQLite.< 1MBOracle Corporation
Snappy DB
AndroidKey-value pairs / NoSQL dbNoNoNoApache 2.0Portable lightweight key-value store, NoSQL db based on LevelDB.Nabil HACHICHA
Realm
Android / iOSObject DatabaseNoNoYes Apache 2.0 License APIs with proprietary sync.Embedded object db.Realm Inc.
SQL Anywhere; Ultralite is the mobile version
Android / iOSRelationalDependantNoAES-FIPS cipher encryption for full database or selected tablesProprietaryEmbedded / portable db with central snyc support with a stationary database.Database memory footprint: only 300KB for mobile devicesSybase iAnywhere
SQLite
embedded on iOS and AndroidRelationalNoNoNo, Use SQLCipher to encrypt SQLitePublic domainC programming library; clear market leader).500KiBHwaci
UnQLite
Android / iOSKey-value pairs / document store / NoSQL dbNoNo2-Clause BSDPortable lightweight embedded db; self-contained C library without dependency.Symisc systems

If you are interested in an indication of the diffusion rate of databases and mobile databases, check out the following database popularity ranking: http://db-engines.com/en/ran.

Thanks for reading and sharing. Please let us know what you’re missing.