|
|
|
|
|
by ncruces
924 days ago
|
|
The performance difference was larger than I had expected. But this is good. To fix a recent crash [1] that was happening due to a particular case of reentrancy, which only showed up when I implemented virtual tables and queried other tables to implement one (e.g.: Go calls sqlite3_step to execute a query, which calls Go because it's a query on virtual table, which calls sqlite3_step to scan another table) I introduced a performance regression. The fix [2] was not to reuse some objects I was allocating once per connection. A mitigation for the regression was (very naive) caching [3]. TLDR: my caching is just not good enough. Simply caching more will go a long way (confirmed already by doubling cache size), but now that I have a good benchmark, I'll do better. I expect to cut numbers for CPU bound tests in half due to this mishap. So, thanks cvilsmeier! [1]: https://github.com/ncruces/go-sqlite3/commit/a9e32fd3f0b9f39...
[2]: https://github.com/ncruces/go-sqlite3/commit/d862f47d95d522f...
[3]: https://github.com/ncruces/go-sqlite3/commit/9c562f5d8bf7436... |
|
In [1] I implemented a simple PLRU bit cache, and I'm seeing an 8x performance improvement in some of the tests I was doing worse in:
Before:
After: There's still work to do. I could use ints rather than strings for function identifiers. I'll evaluate that later.[1]: https://github.com/ncruces/go-sqlite3/commit/964a42c76deb9c7...