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).

I mean I love to see a 0.5% performance boost in my code at work. I would be all over a 5% boost, I think anything above 1% is significant!

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.

That would be my guess as well. Please do let me know what you find, and feel free to open any issues or PRs.

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

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)

Also because there's a mismatch between goroutines and C threads as described here https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... while Java threads can map 1:1 to C threads.

Perhaps someone should define a new C compatible threading API to allow C libraries (including glibc or a wrapper around glibc) to work with something other than native pthreads. Such as goroutines or Java threads and so on.

Many general M:N threading solutions have been tried over the years. As far as I know current thinking is still that you need substantial cooperation from a language runtime to make it worthwhile. (And even then it's hard - Java's first attempt failed and they went 1:1 essentially between 1998-2022.)

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.

That stood out to me as well. Any insights why sqinn and zombie underperform in this case, and is the problem inherent to their design?

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.

I would suspect some unnecessary copying. Nothing else explains a “lower level” binding (zombie) performing worse than modernc.

My (WASM) binding also has a lower level API. But I worked hard to make database/sql work first class, so I wouldn't expect much improvement.

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

At the risk of being overly critical sour grapes, I really had tools like Monibot in mind when creating Catalyst.

Out of the box, Monibot throws a bunch of data at you like database size, CPU %, requests, etc. None of these metrics really tell you if something in your webapp is broken. And if you want more useful metrics, you gotta instrument them yourself.

It does do some things that Catalyst critically misses (health checks, e-mail notifications). But at the same time, if you're going to prod, Monibot by itself is not something you'd be comfortable with. You're going to need to add other monitoring tools to get that peace of mind.