Framework Benchmarks Round 22

Right after Round 21 I’ve worked on the 3 projects delivering:

• an improvement on HTTP parsing for Netty (affecting every Netty-based frameworks, actually, including Vertx and Quarkus), to make it more branch-pred friendly: https://github.com/netty/netty/pull/12321
• found (and fixed) a 20 years old bug affecting a lot of Java programs (and Netty HTTP encoding and Quarkus’s ORM ie Hibernate), see https://github.com/netty/netty/pull/12709 and https://www.youtube.com/watch?v=PxcO3WHqmng&ab_channel=DevoxxUK (and my mate Sanne G. worked to fix the hibernate part -> https://github.com/Sanne): this has delivered a gigantic improvement, especially on Quarkus, better explained at https://redhatperf.github.io/post/type-check-scalability-issue/)
• replaced epoll read/write with recv/send -> https://github.com/netty/netty/pull/12679 (which has delivered a 5-10% improvement on all Netty based servers)
• I’ve been mentor of GSoC 2020 bringing io_uring into Netty (https://netty.io/wiki/google-summer-of-code-ideas-2020.html#add-io_uring-based-transport) and ported it (with @Julien Viet ) in Vertx at https://github.com/vert-x3/vertx-io_uring-incubator

All these changes has improved the performance of the mentioned frameworks from 40% to 200% depending on the test

I would like to use that opportunity to highlight Scala’s “new kid on the block”, Pekko, which is a fork of Akka, and currently undergoing incubation as Apache project. One of the reasons for contributing it to the Framework Benchmarks, was to verify no obvious performance regressions were introduced in the process of forking, and the results look good! Pekko is very much en-par with its legacy counterpart.

List a few of Rust’s performance optimizations.

In a real production environment, several approaches can be tried to optimize the application:

1. Specify memory allocators
   • mimalloc
   • snmalloc-rs
   • jemallocator
2. Declaring static variables
   • once_cell
   • lazy_static
3. Putting a small portion of data on the stack
4. Using a capacity to new vector or hash, a least capacity elements without reallocating
5. SIMD

In general you should not take anything from tfb benchmark and simply consider it useful in real world. Context and use case determines how you optimize your code.

btw: xitca-web (bench code not including dependencies) does not do 2,3,5 and still remains competitive in micro bench can be used as a reference.

I have written a blog post about TFB and object pascal – yes, we added our object pascal framework in round 22! About how we maximize our results for TFB, we tried several ways of accessing the DB (ORM, blocking, async), reduced the syscalls as much as possible, minimized multi-thread locks especially during memory access (a /plaintext request requires no memory allocation), and made a lot of profiling and micro-optimizations. The benefit of the object pascal language is obvious: it is at the same time a high-level language (with interfaces, classes and safe ARC/COW strings), safe and readable, but also a system-level language (with raw pointers and direct memory buffers access). So the user can write its business code with high level of abstraction and safety, but the framework core could be tuned to the assembly level, to leverage the hardware it runs on. Finally, OpenSource helped a lot having realistic feedback from production, even if the project and the associated FreePascal compiler are maintained by a small number of developers, and object pascal as a language is often underestimated.