Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I benchmarked six Go SQLite drivers

github.com

Post reply on HN
Print view View original

61–64 of 64 posts

Re: I benchmarked six Go SQLite drivers

#61

Post by ncruces »

cp9 wrote: post #23

the thing about the mattn driver is that it supports all the features that sqlite itself supports. you can compile in vtables, extra stat stuff, which FTS option you want, anything. and if you use zig as your cross compiler you don't even need separate toolchains for the different arch/OS combos, it all just works

It doesn't support everything. No driver likely does.

An example of one thing missing is the pointer passing interface which limits the ability to create complex extensions. If support was added, the way function creation and virtual tables where wrapped would make it hard to use.

But even more trivial things like a decent interface to incremental blob IO have been left unaddressed.

https://www.sqlite.org/bindptr.html

https://github.com/mattn/go-sqlite3/issues/239

Re: I benchmarked six Go SQLite drivers

#62

Post by ncruces »

ncruces wrote: post #60
ncruces wrote: post #51

I'm the author or the WASM (+wazero) based github.com/ncruces/go-sqlite3. Happy to field questions. W.r.t. benchmark results. wazero's current compiler is somewhat naive, which may explain a large performance delta in CPU bound tests. A new compiler is in the works [1]. OTOH it seems interesting that in the (IO bound?) large test I'm doing better than modernc. I wonder why. I'll dig deeper into the results. [1]: http…

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 introduc…

OK, so if I'm looking at this right, a smarter, wider cache goes a great length to fixing the issue.

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:

  bench-ncruces    -               simple       insert        query       dbsize
  bench-ncruces    -               simple        21224        16495     58687488
  bench-ncruces    -   complex/200/100/20       insert        query       dbsize
  bench-ncruces    -   complex/200/100/20        14993        15228     25354240
  bench-ncruces    -            many/N=10        query       dbsize
  bench-ncruces    -            many/N=10          483        36864
  bench-ncruces    -           many/N=100        query       dbsize
  bench-ncruces    -           many/N=100         3129        36864
  bench-ncruces    -          many/N=1000        query       dbsize
  bench-ncruces    -          many/N=1000        28034        94208
  bench-ncruces    -        large/N=50000        query       dbsize
  bench-ncruces    -        large/N=50000          428    501981184
  bench-ncruces    -       large/N=100000        query       dbsize
  bench-ncruces    -       large/N=100000          779   1003761664
  bench-ncruces    -       large/N=200000        query       dbsize
  bench-ncruces    -       large/N=200000         1475   2007330816
  bench-ncruces    -       concurrent/N=2        query       dbsize
  bench-ncruces    -       concurrent/N=2        13091     56573952
  bench-ncruces    -       concurrent/N=4        query       dbsize
  bench-ncruces    -       concurrent/N=4        14731     56573952
  bench-ncruces    -       concurrent/N=8        query       dbsize
  bench-ncruces    -       concurrent/N=8        24730     56573952
After:

  bench-ncruces    -               simple       insert        query       dbsize
  bench-ncruces    -               simple         5128         3026     58687488
  bench-ncruces    -   complex/200/100/20       insert        query       dbsize
  bench-ncruces    -   complex/200/100/20         3127         3730     25354240
  bench-ncruces    -            many/N=10        query       dbsize
  bench-ncruces    -            many/N=10           93        36864
  bench-ncruces    -           many/N=100        query       dbsize
  bench-ncruces    -           many/N=100          403        36864
  bench-ncruces    -          many/N=1000        query       dbsize
  bench-ncruces    -          many/N=1000         3470        94208
  bench-ncruces    -        large/N=50000        query       dbsize
  bench-ncruces    -        large/N=50000          444    501981184
  bench-ncruces    -       large/N=100000        query       dbsize
  bench-ncruces    -       large/N=100000          717   1003761664
  bench-ncruces    -       large/N=200000        query       dbsize
  bench-ncruces    -       large/N=200000         1401   2007330816
  bench-ncruces    -       concurrent/N=2        query       dbsize
  bench-ncruces    -       concurrent/N=2         3275     56573952
  bench-ncruces    -       concurrent/N=4        query       dbsize
  bench-ncruces    -       concurrent/N=4         3404     56573952
  bench-ncruces    -       concurrent/N=8        query       dbsize
  bench-ncruces    -       concurrent/N=8         4918     56573952
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...

Re: I benchmarked six Go SQLite drivers

#63

Post by ncruces »

ncruces wrote: post #51

I'm the author or the WASM (+wazero) based github.com/ncruces/go-sqlite3. Happy to field questions. W.r.t. benchmark results. wazero's current compiler is somewhat naive, which may explain a large performance delta in CPU bound tests. A new compiler is in the works [1]. OTOH it seems interesting that in the (IO bound?) large test I'm doing better than modernc. I wonder why. I'll dig deeper into the results. [1]: http…

To follow up, I made a new release with performance fixes, and here are the new results: https://github.com/ncruces/go-sqlite-bench/blob/98553a08199b...

Re: I benchmarked six Go SQLite drivers

#64

Post by jchw »

vbezhenar wrote: post #15
acatton wrote: post #12

In my personal opinion and usage, the performance doesn't matter. Only one driver is written in pure go, and can be easily statically compiled and/or cross-compiled. > modernc, modernc.org/sqlite, a pure Go solution. This is a newer library, based on the SQLite C code re-written in Go. Unless I'm mistaken, this is not a re-write in Go. This is a transpilation of the the SQLite C library into go, using https://gitlab.…

Sqlite developers go to very great lengths making sure their software works reliably. You can't just introduce some transpiler in-between and expect that it'll work. It's a different software and it should not even be called sqlite IMO. The only proper way to use sqlite is to use FFI.

If the transpiler is not breaking any defined behavior in C, there is no reason to believe it cannot be a perfectly reasonable solution. There is nothing inherently wrong with targeting another programming language when compiling code, it does not mean there is anything wrong or broken with the generated code or its semantics.

It is a less battle-tested C compiler, sure, but it's a C compiler. IMO, you can't argue that something shouldn't be called sqlite because it contains a transpiled copy of sqlite. To me this isn't really substantially different from transpiling sqlite to JS using Emscripten.

Post reply on HN