I still haven't finished The Scheme Programming Language (TSPLv4) https://www.scheme.com/tspl4/, by Chez's author, but it's incredibly good. He's not shy of saying that Chez is the best Scheme implementation out there, and he might be very right ;)
Even the Racket people thought so. That's saying something. My research as a non-Schemer led me to think highest of Racket (productivity), Chez (dynamic performance), and Chicken (static performance). Chicken might also have good dynamic performance. I don't know since I didn't do detailed comparisons. I just like how they covert things to C to use highly-optimizing compilers. If I did anything about performance, I'd try a Chicken port to see what happens.
Since it's multi-stage, I also considered Chicken might be a good Scheme for a verifying compiler that connected to CompCert C. The result would be both verified and faster compiler than alternatives with latter easier to sell people on. ;) I don't know much about it, though, since I started looking at non-Lisp/Scheme metaprogramming given most programmers' and businesses' adversion to the Lisp-like languages.
Clojure inspires hope that there's some opportunity if one hitches a ride on that bandwagon, though. Esp a native, verified safe/secure, optimized Clojure that still uses JVM libraries. Still keeping that in back of mind tumbling around.
Gerbil http://cons.io based on Gambit, caught my attention. It has a really interesting and rich API and includes what looks like fairly advanced meta-programming facilities. I haven't use it yet, but I found it
It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. Even Lisps seem more consistent in comparison!
Thanks for the benchmarks. Daaaamn, Chez is dominating them! That's gotta be some great engineering behind that compiler. Ok, nevermind, and will just look into Chez, Stalin, and Gerbil. Thanks for the paper: I missed it somehow.
"It's funny how diverse Scheme implementations are, and how they each have different strength and weaknesses. "
Such adaptability was a strength of the Schemes and LISP's. Also their weakness. People could arbitrarily change the languages so much that the software was hard to maintain at a team level. It's why I advocate for simpler, consistent forms for the default way to program with the macros and stuff being use really selectively. And with it clear they're macros. I remember reading from a few people that they did something similar in LISP shops. I don't have much data on that, though.
Back in 2005 I went to the Montréal Scheme User Group and met people who were using Lisp professionally for NLP applied to telecom (voice-controlled automata). A few years later I bumped into one of them again and asked what happened: they were hiring Java engineers. The guy told me that the problem with Lisp is that the code was getting more difficult to understand as layers of abstractions were piled onto one other (people were creating new vocabularies to adapt the system to evolving requirements). He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application.
From my personal experience I find that Lisp, and more particularly Scheme is an amazing way to prototype high-level concepts. Instead of starting off coding right away, I now spend time expressing concepts and structures as S-Expr and pseudo-Scheme as part of the documentation, with the intention of creating a simple Scheme runtime to validate them. However, I probably would not create a production system with Scheme -- I use Python for prototyping implementation, and would probably use Rust now for a production version (as opposed to C).
"He said that although the Java version was architecturally less elegant and more verbose, it was also more straightforward and allowed for less qualified developers to maintain and expand the application."
That's why I was saying maybe we should treat commercial Lisp like any other language with the macros just handling weird situations. Maybe giving us new constructs, optimizing something with obvious meaning, handling portability, and so on. You could say kind of like how D, Rust, and Nim use them.
Boring, predictable code is better in long-term in businesses. So, we make Lisp's boring until boring solution is too painful. Then, we get it clever with clear docs about what's going on. Should prevent their problem, yeah?
People tell me things running on low-level hardware need C or assembly-like languages. You just can't use things like Scheme. Then, you have Scheme on a Z80 in this paper. These two statements don't fit in my brain well together. ;)