On Sunday, 13 September 2020 at 20:58:04 UTC, Daniel Kozak wrote:
> On Sun, Sep 13, 2020 at 9:55 PM ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> Hello
>>
>> ....
>>
>> So i am forced to look at github/dub packages
>>
>>
> What is wrong on this? Dub is official part of D ecosystem so  this is the
> right way. Just select the package you need add it to your dub dependencies
> and thats all.
> There is vibe-d, hunt and maybe others packages which do what you need. I
> do not see any advantages to have this in phobos.

maybe i am just a different demographic..

What i mean is the dependencies, it being a dub package, doesn't prevent author from pulling ton of other dependencies

If it was in the std lib, it would stay simple, without the need of external dependencies

And everyone could contribute making it as fast as possible, making all other middleware profit from the improvements by default


Dependencies feals heavy, the less you have, the better it is

And there is nothing wrong with dub/github, for such heave used kind of API, it deserve a place in the std lib in my opinion

On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:
> On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>>
>> Concerning vibe.d, i'm worried about the dependencies it pulls, also the benchmark:
>>
>> https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r
>>
>> GO vs D, it performs quite poorly
>>
>> This benchmark is not perfect, vibe-d is fast, I can even rewrite those
> benchmark to make vibe-d same fast as actix-core.
> So I would not be afraid of vibe-d performance.

I think it needs to be updated then, that would clear some of my concerns about vibe.d

I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow

On Sunday, 13 September 2020 at 21:09:48 UTC, ryuukk_ wrote:
>
> Can you show me how to setup an HTTP listener and with simple routes using std.net.curl?

Sorry, I mixed up client and server here. No you can't.

On 9/13/20 5:16 PM, ryuukk_ wrote:
> I think it needs to be updated then, that would clear some of my concerns about vibe.d
> 
> I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow

I haven't double checked vibe-d's benchmark code, but FYI many of the other "ultra performant" frameworks are essentially cheating (even if staying within the rules) by optimizing code paths to work ONLY for the benchmark. For example, instead of matching on the route, they match on the first character of, or the length of the route.

On Monday, 14 September 2020 at 02:01:09 UTC, James Blachly wrote:
> For example, instead of matching on the route, they match on the first character of, or the length of the route.

So that's kinda sorta cheating, but like that kind of thing is one of the reasons why code like my cgi.d is why it is: you can use as much or as little of it as you need.

For some programs, i use the fancy page generation framework. For others, I just write("hello world"). That's the way the lib is intended to be used, so I wouldn't really call it cheating if theirs are that flexible too.

On Sun, Sep 13, 2020 at 11:20 PM ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
>

As others already pointed out, it is not thats vibe-d perform bad. But the
others use some not so nice tricks to be so fast.
This is why I say I can make vibe-d same fast as the others, but it would
be cheating from my perspective.

They do not real http parsing, they generally just  match only the minimum
what they needed.
They use static buffer with already prepared responses
They do not send all http headers
They use one char Server name http header.

So when I use vibe-d without the http package and just use TCPconnection and do the same as the others I would have the same speed, but this is not what you generally want.

On Mon, Sep 14, 2020 at 7:39 AM Daniel Kozak <kozzi11@gmail.com> wrote:

> On Sun, Sep 13, 2020 at 11:20 PM ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>>
>> I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
>>
>
> As others already pointed out, it is not thats vibe-d perform bad. But the
> others use some not so nice tricks to be so fast.
> This is why I say I can make vibe-d same fast as the others, but it would
> be cheating from my perspective.
>
> They do not real http parsing, they generally just  match only the minimum
> what they needed.
> They use static buffer with already prepared responses
> They do not send all http headers
> They use one char Server name http header.
>
> So when I use vibe-d without the http package and just use TCPconnection and do the same as the others I would have the same speed, but this is not what you generally want.
>
>
But to be fair, there are many places where vibe-d performance could be
improved:
There is a big penalty when you use keep-alive smaller then Duration.max
vibe-d write headers independet from body content which is one of other big
performance penalty
vibe-d do address translation with each request thats other performance hit

On 2020-09-13 23:08, ryuukk_ wrote:

> What i'm after thought is the phsycological part of it, getting started now involves having to consume a dependency, just to get an http listener

I can really agree with this. For someone new to the language and the ecosystem it can be difficult to find which dependency is the "right" choice to pick.

-- 
/Jacob Carlborg

On 2020-09-13 22:58, ryuukk_ wrote:

> Concerning vibe.d, i'm worried about the dependencies it pulls, also the benchmark: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r 

I did some benchmark on some real world code at my previous work. We compared the performance (number of requests per second) of an HTTP endpoint. It fetched some data from a PostgreSQL database, did some processing and returned the result as JSON.

We compared a highly optimized version implemented in Ruby, this was the baseline. Then a colleague implemented a version in Go and I did an implementation in D, using vibe.d .

The end result was that the Go version ran at 0.5x of the Ruby version and the D version ran at 5x of the Ruby version. This was without trying to optimize the code afterwards. Only some common sense while writing the code, like if you can do it at compile time, do that. I'm pretty sure I didn't even used LDC for an optimized build.

Of course, everyone at the company was only talking about how on earth the Go version could be slower than the Ruby version. Someone later did some improvements so that the Go version was up to the same speed as Ruby. Nobody talked about how much faster the D version was, except me :( .

-- 
/Jacob Carlborg

On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
> On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:
>> On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>>
>>> Concerning vibe.d, i'm worried about the dependencies it pulls, also the benchmark:
>>>
>>> https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r
>>>
>>> GO vs D, it performs quite poorly
> I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow

Did you take a look at hunt?

https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1r