[SPIKE] Status-go Database performance investigation

[jrainville]

Description

We need to figure out what are the actual main causes of the status-go database slow downs/locks.

We have a couple of ideas. We need to test them out.

Notion document to document the ideas and findings: https://www.notion.so/Database-related-performance-1dbaa7ea894c461d885e55676683be07

• [Performance] Slow sqlite queries due to burn_stack and zeromem #10572
• [Performance]Test status-go DB pool #10611
• [Performance] optimize sha1 performance #10559
• [Performance] optimize AES (rijndael) performance #10726
• [Performance] Implement DB connection pool to wrap go-sqlcipher connection #10723
• [Performance] Test different DB configurations (4096+ page size, new SQLCipher and SQLite versions) #10753
• [Performance] Profile database queries #10588
• [Performance] enable multiple db connections with sqlcipher #10767
• [Performance] Stop/slow-down importing archives when app in focus #10815
• [Performance] start archives import with delay #10937

[jrainville]

cc @iurimatias @John-44 @cammellos if you want to follow the progress

[caybro]

Coincidentally, I was also looking into this today and so I fired the excellent hotspot tool and here's a couple of findings from running the app for about 2-3 minutes (usual "messenger" session):

36% of all CPU cycles is spent inside sha1_compress:

The same, using top-down breakdown:

Going into even more detail, 27% of all CPU cycles is spent on this single line, still inside sha1_compress:
(https://github.com/mutecomm/go-sqlcipher/blob/25f68adb9fb3bc95229bee7e3498a6ca2f3e752d/sha1.c#L61)

[caybro]

(I can upload the raw perf.data file, if anyone's interested in inspecting and visualizing this on Linux)

[caybro]

I hope it gives at least some insight where (and what) to start looking in first :) The sha1 looks like an ideal candidate for some vectorization (OpenSSL uses MMX/AVX512 or even SHA extensions found in recent Intel/AMD CPUs), I assume that implementation must be orders of magnitudes faster

[John-44]

I hope it gives at least some insight where (and what) to start looking in first :) The sha1 looks like an ideal candidate for some vectorization (OpenSSL uses MMX/AVX512 or even SHA extensions found in recent Intel/AMD CPUs), I assume that implementation must be orders of magnitudes faster

Do you want to talk a look at the specific issue you've identified here (optimise sha1_compress)? ;-)

I think (but somebody correct me if I'm wrong) that looking into optimisation of sha1_compress is complementary with everything else discussed today. If you do want to take a stab at this, I would recommend creating a seperate issue for just this task.

[caybro]

I hope it gives at least some insight where (and what) to start looking in first :) The sha1 looks like an ideal candidate for some vectorization (OpenSSL uses MMX/AVX512 or even SHA extensions found in recent Intel/AMD CPUs), I assume that implementation must be orders of magnitudes faster

Do you want to talk a look at the specific issue you've identified here (optimise sha1_compress)? ;-)

I think (but somebody correct me if I'm wrong) that looking into optimisation of sha1_compress is complementary with everything else discussed today. If you do want to take a stab at this, I would recommend creating a seperate issue for just this task.

Deal ;)

[alexjba]

• [Performance] Slow sqlite queries due to burn_stack and zeromem #10572