Leaderboard

@Joe Sansalone, I don't have any hard numbers to share. But, we did run some informal benchmarks when testing our workload way back when encryption feature was being developed. On average, we found that full database encryption (for data at rest) introduced a 5-10% performance impact depending on the encryption key strength used. Of course, full database encryption encrypts only "user data" related data pages, but for the whole database. So, if you have a large enough database in-memory cache, and your "write" activity is minimal, you will mostly incur only "decrypt" cost when loading your database pages into memory. Pages are unencrypted when residing in in-memory cache. Simultaneous user requests don't add any further load to the decryption mechanism. If you have high level of "write" activity, the "encrypt" cost for these database pages will also add to the performance tax. You can offset some of this, if you use InterBase short-term Journaling for synchronous writes (database file writes will be async automatically at checkpoint intervals) resulting in only delta changes written to the journal rather than a whole database page immediately. OTOH, a Column-Level Encrypted database, will have far less negative impact on performance than a fully encrypted database for individual requests. Your mileage may vary as to how many columns are encrypted in your database, and in what strengths. But, column-level encryption could have a larger negative impact if you have hundreds of simultaneous requests accessing those encrypted column data. Each request now has to "decrypt" the column data when fetching the "row" from the database page. For OTW/SSL (network encryption), I understand that the performance impact could largely be felt at establishing the SSL "connection" as compared to an unencrypted TCP/IP socket connection. Since we use OpenSSL for our network encryption, I am sure the data packets encrypted/decrypted between InterBase Client and Server through this encrypted channel will incur some CPU charge (heard about 10%-25% addition from conversations many years ago). If your system architecture allows you to have a Connection Pool setup ahead of time, and then shared by your application threads communicating with the server, the "connection" time can largely be inconsequential over time. The data load though will continue to incur the encrypt/decrypt cost at either end of the encrypted channel. IIRC, you use InterBase Change Views. Providing your Change Views usage is factored in, you are already reducing large data sets from being sent to the client application; so, the impact should be fairly painless thanks to Change Views usage adding to bandwidth savings. You may already know this. But, encrypted (database and column-level) databases have a restriction that they can only be backed up and restored using the InterBase service manager component (GBAK, IBConsole supports this); so, network bandwidth impact is eliminated because of this. Backup/restore is most data intensive, and glad to note that encryption does not impact performance adversely here. A couple questions for you... 1. What kind of database connection and request load do you anticipate? 2. Do you have a middle tier using any custom connection pooling? 3. Have you though of using some VPN layer implementing encryption at the network level, and just use InterBase Client and Server to communicate through this network provider? 4. Do your client applications communicate to systems over WAN or to public cloud environments? Hope this helps.

I've managed to fix it by myself. What I did was to: 1) Download archive file, containing the customized units and libraries of the Midas library from here: https://www.4shared.com/rar/rGEOSrkNea/Arquivos_Delphi_Rio_1033.html and follow the instructions to replace the libmidas.a libraries for Android / Android 64 from the video below: My libmidas.a files are located by default: - for Android 64 Release in: C:\Program Files (x86)\Embarcadero\Studio\21.0\lib\android64\release - for Android Release in: C:\Program Files (x86)\Embarcadero\Studio\21.0\lib\android\release 2) Added in Rad Studio - Tools / Options / Library the following paths for: - Android 64-bit: C:\Program Files (x86)\Embarcadero\Studio\21.0\lib\android64\release - Android 32-bit: C:\Program Files (x86)\Embarcadero\Studio\21.0\lib\android\release I am not saying this is the only fix of my problem, but this is my workaround to FIX it and it's WORKING !

It supports Android 4.1 JellyBean+. I will test it ASAP.

Delphi strings are managed types so they are never ill-defined in the way that unmanaged types can be before first assignment. Note that this assumes correct practise. So if you use GetMem rather than New to allocate memory for a managed type then the above statement is not correct, but then doing that would be incorrect practise.

DUnit is not actively being maintained, true. But I am planning to keep on using it - it achieved a nice balance between being flexible enough but at the same time very simple and not overengineered, ymmv. I don't care what some guy in that issue says - they have been doing modifications to DUnit themselfes for ages and suddenly its a DUnit issue they cannot/don't want to fix? How ridiculous tbh. I have my opinion about DUnitX - but it's certainly not deprecated but Vincent does not care for adding C++ support afaik. I was in fact looking into dusting off DUnit, removing old cruft like the CLR stuff and applying some optimizations such as making parameters const, reducing unnecessary overhead in Check methods and so on (doing so improves the overall runtime of my tests by like 10% simply because the CheckSomething methods are faster!) while doing that I could look into making it work with C++