[sltr]

The library's tagline says "Powerfully Simple. Blazingly Fast." So there. ::folds arms::

Joking aside, I do agree that ASP.NET Core is a behemoth. On .NET 9, I just now did `dotnet new webapi` followed by `dotnet publish --self-contained -p:PublishSingleFile=true` and the binary is 103MB. That would blow up the size of a mobile app considerably, just to listen to HTTP.

There a separate use case that SimpleW won't solve: When you're on a platform that .NET Core doesn't support, like Raspberry Pi Zero (armv7l). In this case all you have is the mono framework and binding to raw ports.

[prodbro]

> The library's tagline says "Powerfully Simple. Blazingly Fast."

> Joking aside

author here.

I agree with your remark ^^

Each time i read some news about a new framework with tag "blazingly fast", i'm thinking "lol".

So i had to resist to the temptation... And finaly when doing a small benchmark, performances were not bad at all (https://stratdev3.github.io/SimpleW/guide/performances.html) and i let the "clickbait" title.

My targets are small to medium traffic and embeded devices (dotnet/android).

[qingcharles]

Did you try compiling all the test to native thru AoT? There are probably some optimizations to improve the Kestrel score by altering the config, or maybe changing how the API is written:

app.MapGet("/api/test/hello", () => "Hello World!");

As a general web server, I think I'd always go for Kestrel over this, but as another poster said, if you're trying to add an endpoint to some desktop application, this would be perfect.

[prodbro]

> There are probably some optimizations to improve the Kestrel

You're right.

To be fair, i have to run many other benchmarks including one with the best recommanded optimizations for each projects.

a little time consuming but definetely on my todo list.

[stackskipton]

Most of that is runtime taking up space. So yes, baseline is 103MB but outside that, it's not likely to balloon too much past assets. Compared to Python/Node/Java/Ruby containers I see as SRE, 103MB is god send.

I think you are expecting too much here.

[andix]

> On .NET 9, I just now did `dotnet new webapi` followed by `dotnet publish --self-contained -p:PublishSingleFile=true` and the binary is 103MB.

I've just tried the same, but with native-aot (build to native code). On Windows it was around 10mb, including routing, JSON serialization and openapi support. Startup is nearly instant.

If you include the dotnet runtime it's much bigger, but that's expected.

Edit: built with dotnet publish -r win-x64 -c Release /p:PublishAot=true /p:PublishTrimmed=true /p:PublishSingleFile=true

[crinkly]

Sometimes. It's usually a lot bigger than that the moment you pull in any simple dependencies. Also the CLR memory overhead is horrible. Our .Net guys have serious problems with startup time (JIT) and initialy latency on .Net Core so I don't trust the fast claim. And no you can't just AOT everything.

We moved a couple of critical services over to Go because of those two issues and it turned a few heads.

[magicalhippo]

Curious what the use-case is where JIT latency is an issue for a http service?

[crinkly]

We are fairly high traffic. Deployments, even rolling, can and do cause fairly noticeable latency spikes and side effects like upstream services having to queue requests, pool escalations, all sorts. Warming stuff up before first hit is a complete bitch on top of that.

I notice Apple had similar problems and moved some of their back end to Swift from JVM recently. There was a post on here.

[stackskipton]

Yep, downside of virtual language like that. Upside of Java/.Net is their extensive libraries and really good developer experience. Just like Golang GC caused Discord endless amount of headaches in some of their routes.

I have some heavy ASP.Net stuff too, yep, we have to prewarm it before putting into production.

[fabian2k]

Probably Serverless functions, which is a use case where standard ASP.NET Core is not particularly good.

I'd blame Serverless more than ASP.NET Core for the bad performance in that case though.

[zigzag312]

Enable trimming

[sltr]

Simple claim with a complex story.

I thought about mentioning AOT and trimming, but my comment was already long.

AOT in ASP.NET is still a moonshot in most cases, and a non-starter in existing web apps due to dependencies not supporting AOT.

Worth mentioning that as of .NET 9 AOT is not supported on Android.

[actionfromafar]

Soo many dependencies do not support AOT.

[mlhpdx]

And AoT.

[dardeaup]

I hate when someone's software advertises itself as 'blazingly fast' and then provides NO DATA to back up the claim. It's possible that it really is blazingly fast, but to make the claim and provide no data is sad. In God we trust - all others please bring data.

[prodbro]

> I hate when someone's software advertises itself as 'blazingly fast' and then provides NO DATA to back up the claim

agree, that's why there is a performance benchmark at https://stratdev3.github.io/SimpleW/guide/performances.html with code as you can reproduce at your own.

i'm adding other tests, more complete than the hello world one.

[dardeaup]

Cool! Please add link to that page from your github project's main page.