cvilsmeier

According to my private tests, using STATIC instead of TRANSIENT does not yield a significant performance boost (maybe 1 to 5 percent, if at all).

You're right. A table. I've included one.

Thank you.

You are correct: Multiple connections means multiple sqinn subprocesses.

> How come Zombiezen came out faster ? I’d expect the opposite

(OP here) Honestly, me too. Maybe it has to do with leaving out that database/sql driver layer. I guess it would need another round of pprof to find out the real reason.

Nothing wrong with it, but there are other drivers that cross-compile better and are faster.

For sqinn it's because of its design: Shuffling that much data over process boundaries takes time. For zombie, more pprof would be needed to explain the behaviour.

Yes, in fact the benchmark started out as a comparison between sqinn and mattn. (There was no modernc at that time.)

Maybe because Go devs are more allergic to 'non-Go' solutions that Java devs are to 'non-Java' solutions? (Explain: Java's xerial driver is a DLL/SO wrapped in a Java library)

Sqinn author here. Yes, sqinn performs quite well compared to the 'standard' mattn driver. The only use case it clearly breaks down is when SELECTing very large (gigabytes) resultsets.

If you want to monitor custom app metrics and server resource usage, you can also try Monibot. It's not comparable to catalyst, though.

I did: https://monibot.io

I'm a developer. I write web apps and run them on linux servers. I keep an eye on them to make sure all apps are running smoothly. But, as the number of apps and servers grows, manual monitoring takes more and more time, so I need an automated web app monitoring tool.

I use it for SQLite Database access in Go and Java. Java lets you theoretically interface with C code, but it's a lot of JNI/DLL/SO work. It's much easier for me to just os/exec (or Runtime/exec in Java) and send data back and forth. Your mileage may vary, of course.

> But compiling the non-go assistant process is not going to be any easier than cgo, right?

Right. But you have to do it only once, or you can download a pre-built library from https://github.com/cvilsmeier/sqinn/releases (windows/amd64 or linux/amd64)

> you may as well run MySQL

You're right, there are use-cases where SQLite is not appropriate. But nothing beats the ease of installation/backup/maintenance of SQLite compared to server databases like MySQL or Postgres. Another point is development: For unit-tests, I found that initializing a SQLite database for each test-run is much easier (and faster) than having a VM that runs Postgres/MySQL/etc, which I have to spin up and tear down before/after each test run.

> Wow, that sounds incredibly inefficient!

That's exactly what I thought, too. But, to my own surprise, it's as fast as CGO solutions, in most cases even faster. You may check here: https://github.com/cvilsmeier/sqinn-go-bench

Thank you! Nice to hear :-) Use the code any way you want, it's unlicensed.

Sqinn author here. Nothing against CGO, but I develop/deploy on Win/Linux, and cross-compiling CGO is very painful. Regarding performance: To my own surprise, Sqinn out-performs mattn (and others) for normal workloads, see https://github.com/cvilsmeier/sqinn-go-bench