Vix.cpp Core v2.6.3: Official Benchmark Baseline

Today I reached an important milestone with Vix.cpp Core.

For the first time, I now have an official benchmark baseline for Vix.cpp Core v2.6.3.

This baseline was generated in Release mode on Linux x86_64 using GCC 13.3.0.

The goal is simple:

I do not want to say “Vix is fast” only because it feels fast on my machine.

I want performance to be measured, tracked, compared, and protected.

Why this matters

When building a C++ framework, performance can easily regress without being noticed.

You change a router function.
You improve an executor.
You refactor request parsing.
You clean up response serialization.

Everything still compiles.
All tests still pass.

But maybe the router is now 15% slower.
Maybe request construction got heavier.
Maybe the runtime scheduler is doing more work than before.

Without benchmarks, you may not see it.

With a baseline, every future change can be compared against a known reference.

That is why I started building the official Vix.cpp Core benchmark suite.

What is currently benchmarked

The benchmark suite currently covers several parts of Vix.cpp Core:

runtime queues
runtime scheduler
runtime workers
executor submit/post
executor metrics
router matching
router registration
HTTP request handling
HTTP response generation
fake transport sessions
app route registration
app group registration

This gives me visibility across both low-level primitives and higher-level web framework behavior.

Some results from the v2.6.3 baseline

Here are some numbers from the current Release baseline.

Runtime

runtime.queue/try_steal_empty                    132.6M ops/sec
runtime.queue/push_pop                            49.6M ops/sec
runtime.worker/steal_callback_complete_tasks       9.3M ops/sec
runtime.scheduler/submit_affinity_tasks            1.07M ops/sec

Router

router.match/static_route          9.37M ops/sec
router.match/nested_static_route   8.17M ops/sec
router.match/param_route           5.67M ops/sec
router.match/nested_param_route    3.91M ops/sec

This is useful because it shows the natural cost difference between static routes and parameterized routes.

A static route is faster.
A nested parameterized route is more expensive.
That is expected, but now it is measured.

Executor

executor.metrics/idle_reads        112.2M ops/sec
executor.submit/task_complete        465K ops/sec
executor.post/void_tasks             397K ops/sec

The executor benchmarks help track the cost of scheduling work, posting tasks, reading metrics, and handling different task execution paths.

HTTP

http.request/default_construct       10.7M ops/sec
http.request/json_cached_access      15.7M ops/sec
http.response/to_http_string_json    1.02M ops/sec
http.response/to_http_string_text     547K ops/sec

These benchmarks help protect the request and response layer, which is critical for Vix.cpp web applications.

Session

session.fake_transport/single_get_health      146K ops/sec
session.fake_transport/keep_alive_pipeline    248K ops/sec

This gives a higher-level view of request processing using an in-memory fake transport.

It is not the same as a real network benchmark, but it is very useful for tracking framework overhead without depending on external network noise.

Build mode matters

One important lesson: official benchmarks must not be generated from a debug/dev build.

A dev build is useful for testing and debugging, but not for official performance numbers.

For Vix.cpp Core, the rule is now:

dev / debug = compile, test, debug
release     = measure performance

The official baseline must come from a Release build.

How I want to use this

From now on, when I make a serious change inside Vix.cpp Core, I can run the benchmarks again and compare them against the v2.6.3 baseline.

If performance improves, I can prove it.
If performance gets worse, I can see it.
If a regression appears, it should not be ignored.

This changes the development workflow.

It moves performance from opinion to evidence.

Why I care about this

Vix.cpp is not only a C++ experiment for me.

I want it to become a serious foundation for building web services, runtime systems, tooling, and production applications.

For that, tests are not enough.
Documentation is not enough.
The framework also needs measurable performance discipline.
Benchmarks help create that discipline.
They make the project more honest.
They make future changes safer.
They make performance visible.