# Deleting performance is too slow **URL:** \ **Category:** Issues\ **Created:** [September 2, 2022, 7:52am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536 "2022-09-02T07:52:23Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 2, 2022, 7:52am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/1 "2022-09-02T07:52:23Z")
When I use SQLcipher and execute ‘delete’ to delete 30000 rows, the performance becomes slower.’ Update 30000 rows 'only takes 900 milliseconds . When I don’t use SQLcipher, it only takes 1300 milliseconds to delete 30000 rows, and it takes 6700 milliseconds to delete 30000 rows using SQLcipher This is my configuration： PRAGMA cipher\_memory\_security = OFF PRAGMA secure\_delete = 0; PRAGMA journal\_mode = WAL; SQLCipher version: 4.4.3 ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 5, 2022, 6:21am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/2 "2022-09-05T06:21:34Z")
I wish someone could help me ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 5, 2022, 6:28am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/3 "2022-09-05T06:28:53Z")
I see that SQLcipher forces the use of secure\_delete. Could this be the reason for the slow performance? Is there any way not to use secure\_delete ---
**Author:** ![sjlombardo](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/sjlombardo/32/3_2.png) [@sjlombardo](https://discuss.zetetic.net/u/sjlombardo)\ **Post date:** [September 6, 2022, 6:17pm UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/4 "2022-09-06T18:17:40Z")
Hello @qwp767972675 - Large deletes are probably a “worst case” scenario for SQLCipher because they involve reading the database to identify affected rows, decrypting each page, rewriting and scrubbing it, encrypting, and writing back. Here are the general recommendations for performance optimization [SQLCipher Performance Optimization - Zetetic](https://www.zetetic.net/sqlcipher/performance/) Specifically from that list, you should make sure the schema is normalized (to minimize size and number of records requiring deletion), appropriate indexes are in place, and that deletes are being grouped up into transactions. Outside of that, you might be able to get some further performance improvements with one or more of the following 1. use WAL mode (PRAGMA journal\_mode = WAL) 2. disable secure delete (PRAGMA secure\_delete = OFF) 3. disable HMAC (PRAGMA cipher\_use\_hmac = OFF) 4. increase page size (PRAGMA cipher\_page\_size) ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 9, 2022, 6:13am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/5 "2022-09-09T06:13:19Z")
What I find strange is that when I change delete to UPDATE, I get a big performance boost, and I set PRAGMA cipher\_memory\_security = OFF, delete takes 6.7 seconds. The UPDATE takes only 1.2 seconds ---
**Author:** ![sjlombardo](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/sjlombardo/32/3_2.png) [@sjlombardo](https://discuss.zetetic.net/u/sjlombardo)\ **Post date:** [September 9, 2022, 5:16pm UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/6 "2022-09-09T17:16:23Z")
When you run the update are you actually changing every column of the affected row? ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 14, 2022, 8:50am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/7 "2022-09-14T08:50:43Z")
Yes, when I run UPDATE, every row is changed ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 14, 2022, 8:52am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/8 "2022-09-14T08:52:38Z")
As I understand it, SQLITE3 internally just marks the data when SECURE\_DELETE is off and doesn’t actually erase the content, so the performance should be similar to UPDATE. ---
**Author:** ![sjlombardo](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/sjlombardo/32/3_2.png) [@sjlombardo](https://discuss.zetetic.net/u/sjlombardo)\ **Post date:** [September 14, 2022, 3:42pm UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/9 "2022-09-14T15:42:08Z")
Hello @qwp767972675 - can you provide access to a sanitized (clean of sensitive information) standalone database and the associated statements that would reproduce this problem? ---
**Author:** ![qwp767972675](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/qwp767972675/32/1859_2.png) [@qwp767972675](https://discuss.zetetic.net/u/qwp767972675)\ **Post date:** [September 15, 2022, 3:58am UTC](https://discuss.zetetic.net/t/deleting-performance-is-too-slow/5536/10 "2022-09-15T03:58:06Z")
Thank you for your patient reply. I think I have solved my problem. I tried to use HMAC\_SHA1 algorithm, and the encryption library was migrated from Tomcrypt to Open SSL. -o2 was added to the compile option, using PRAGMA cipher\_page\_size = 8192; , resulting in a performance improvement of nearly five times