V: pure v server

[enghitalo]

challenge to make V top 1, and then rewrite the veb library

Local results

v wipe-cache && v -prod -gc none -d no_bounds_checking crun .

wrk --header 'Connection: keep-alive' --connections 512 --threads 16 --duration 30s --timeout 1m http://localhost:3000/
Running 30s test @ http://localhost:3000/
  16 threads and 512 connections
^C  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.36ms    1.37ms  22.13ms   86.44%
    Req/Sec    27.40k     1.93k   41.81k    73.89%
  11572012 requests in 26.56s, 1.01GB read
Requests/sec: 435704.00
Transfer/sec:     39.06MB

v wipe-cache && v -prod crun .

wrk --header 'Connection: keep-alive' --connections 512 --threads 16 --duration 30s --timeout 1m http://localhost:3000/
Running 30s test @ http://localhost:3000/
  16 threads and 512 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   876.87ms    2.07s   18.24s    88.71%
    Req/Sec    20.68k     7.18k   48.84k    73.25%
  9871316 requests in 30.10s, 0.86GB read
Requests/sec: 327950.45
Transfer/sec:     29.40MB

[JalonSolov]

Should be named server.c.v

[JalonSolov]

If you do not change the name of this file, it will fail to compile when V changes the default so that files with C. references in them must have .c.v extension.

[waghanza]

Maybe use v instead of vanilla for the reference implementation

[enghitalo]

╰─ wrk -t16 -c512 -d30s http://127.0.0.1:3000/ ─╯
Running 30s test @ http://127.0.0.1:3000/
  16 threads and 512 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.58ms    1.91ms  16.50ms   71.88%
    Req/Sec    13.47k   627.78    25.90k    78.45%
  6450599 requests in 30.10s, 578.27MB read
Requests/sec: 214307.56
Transfer/sec:     19.21MB

[waghanza]

Timeout on /user for raw v implementation @enghitalo
https://github.com/the-benchmarker/web-frameworks/actions/runs/11753378945/job/32746167449?pr=7932

[cyrusmsk]

I'm not sure that such low-level unsafe and "static" (return string instead of generated HTTP response) implementation should be used in the benchmark

[waghanza]

You say @cyrusmsk , that having such an implementation is not usefull here.

It's quite the opposite for me. I think this raw implementation (v here) is useful when comparing other with v frameworks, not very useful when you compare with ruby based frameworks (example)

[cyrusmsk]

You say @cyrusmsk , that having such an implementation is not usefull here.

It's quite the opposite for me. I think this raw implementation (v here) is useful when comparing other with v frameworks, not very useful when you compare with ruby based frameworks (example)

I just followed initial message (written somewhere) that the idea of the project is to have production-ready solutions.
And I don't see why the overall code couldn't be prepared as a library and installed from package management of V and used as other libraries (having only high level interface for the user).

[waghanza]

You have a point.

The main goal of this project is to compare web frameworks, so as you can decide wich to choose (if you want to migrate, or create a new project with a business idea or not).

However, to make great framework, contributors need to compare with some reference implementation (in this case pure v for v based frameworks).

For this it could be valuable, but indeed not got the primary goal.

[enghitalo]

My intention with this project is to take advantage of Mr. @waghanza 's incredible project to have a standardized reference point between our frameworks and the frameworks of other projects in other languages ​​and, thus, be able to outline, in a more coherent way, the performance improvements that we can have within the Language.

[ylluminate]

I think @enghitalo's goal is spot on here. The idea of a "vanilla" (non veb-based in this case) starting point is of value and then from there it appears that he will implement a veb-based version (since that is the primarily official "batteries included" option) and perhaps other V-based frameworks.

[waghanza]

Let's fix the CI and I will update results today 😌

[cyrusmsk]

My intention

It is clear and a nice target, I agree. Why not create a separate V package? and put all low-level code over there and provide only high-level interface to it?

[enghitalo]

My intention

It is clear and a nice target, I agree. Why not create a separate V package? and put all low-level code over there and provide only high-level interface to it?

Soon

[waghanza]

Could master be considered as stable ?

I mean since v is not at 1.0, it could be ok to point to master, but it could be inconvenient to fix compilation issues (or else) in there is some

[ylluminate]

That seems reasonable to me. V is so fast moving at the moment that this definitely makes sense @waghanza. I frankly don't think anyone is going to want to support older snapshots with so many updates coming in constantly and consistently... but I should defer to @enghitalo on his intention here.

[enghitalo]

@waghanza For now, master is as stable as previous releases. I changed to master because "weekly.2024.49" is breaking the CI.

[ylluminate]

Good work @enghitalo!

[enghitalo]

Good work @enghitalo!

Thank you!