I get a huge performance issue in my use of the scrypt library (+30 seconds to run it!)
Any ideas why upgrading SQLCipher would affect scrypt?
Would you provide some additional details about the scenario you are referring to? A quick review of your scrypt library source shows no dependency on SQLCipher for Android. Are you using the two libraries in conjunction within a single application? How are you using SQLCipher for Android? The full set of changes between 3.5.4 and 3.5.7 can be seen here.
Without knowing more specific information about the application, and any possible intersection between SQLCipher for Android and your scrypt implementation it is difficult for us to speculate what the issue may be. If you can provide more details about what capacity SQLCipher for Android is being used, and what if any interplay your scrypt library has during execution, we may be able to help diagnose the behavior further. We have a writeup on general SQLCipher performance that you may find beneficial in troubleshooting further.
re: what is the apparent source of the slow down, is it executing scrypt or SQLCipher calls?
After some more investigation, I’ve found the reason for the slow down is doe to the failure to load the native libary for scrypt. This happens after moving from 3.5.4 to 3.5.5 so I assume this happening due to the 64 bit upgrade of SQLCipher, so the system is also trying to load the 64bit version of Scrypt (which doesn’t exist). Since it can’t load the scrypt library, it defaults to the Java version, which is why it is so much slower.
Since I don’t yet have 64bit versions of scrypt, and I believe you can’t mix 32 and 64 bit versions of libraries I’ve forced the use of 32bit SQLCipher via:
Yes, the newer builds of SQLCipher for Android did add 64-bit support. Excluding 64-bit native libraries from your application in the interim sound appropriate as the 32-bit versions of the libraries will run on 64-bit CPU’s.