Lock contention in ForceLogPrepare
Profiling code that writes to multiple separate sqlite databases concurrently using System.Data.SQLite it looks like a fair bit of time is spent waiting for the lock in ForceLogPrepare, about 30% in my test.
I haven't been able to build System.Data.SQLite locally to test if it is just the profiler or performance actually would improve if replacing the lock in ForceLogPrepare with for example an enum and double checked locking or Lazy<bool>.
Building a netstandard build gives me native api errors when I use it and the .net framework projects give me nuget errors. Can anyone else build?
(2) By mistachkin on 2021-06-07 17:35:59 in reply to 1 [source]
There is now an experimental change on trunk that attempts to address this issue, here: