I'm working on a project that does several inserts like 500 000 (inside a transaction of course).
On my iPad Pro, with classic GRDB I achieve the insertions in 10 seconds which is ok I suppose cause 500k is quite a lot.
By just changing to pod 'GRDB.swift/SQLCipher' the insert time goes up to 35 seconds.
Plus I start getting somme "Received memory pressure event 2 vm pressure 0"
Am I doing something wrong ? Is there a way to improve this ?
Thanks in advance for your help.
It looks like the performance question would be better asked to the SQLCipher team, since you do not have any problem with the standard SQLite. Generally speaking, if you're after the best insertion performance with GRDB, check the discussion at Performance issues · Issue #926 · groue/GRDB.swift · GitHub
I don't know where the memory issue comes from, especially if you do not experience it with the standard SQLite. I recommend you run your app with Instruments, and gather some actual data and preliminary analysis. Please bring your experience to Possible memory issue · Issue #944 · groue/GRDB.swift · GitHub.
Hello again @gwendal.roue ,
First of all, thank you for taking the time and thank you for all your work on this great lib
Posting an update .
I've been talking with the SQLCipher guys, here is the thread if someone is interested.
For the moment it seems that in my test configuration the delta between cipher vs no cipher is normal. Using the
PRAGMA cipher_memory_security = OFF;
is a must while doing insertions in a transactions in such a way.
The mentioned memory issues comes with the way I'm doing things. That's why I was receiving warnings and that's why an insertion of 1 million items makes my iPhone 8 simply crash due to memory pressure even without SQLCipher
Using a prepared statement as you suggested definitely helps with memory but it's actually quite slower.
I've created a test project to test a high number of insertions (with or without a prepare statement)
Maybe I'm doing something wrong but I don't see a way of improving this.
Also I have to confess that I just discovered your comment here
Also, mind that development builds are slowed down by the liberal use of assertions. Performance tests are only relevant in the release configuration.
Indeed the insert time with a prepare statement is really improved in release.