-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add httpbeast #295
Comments
@dom96 does |
Depends how sophisticated the routing has to be. It is pretty barebones though. |
Is doing some string handling acceptable? if request.path.startsWith("/user/"):
let id = request.path[6 .. ^1] |
tbrand didn't accept that identical testing in the C++ version though, hence why it was converted to the slower regex path matcher. ;-) |
But why? :( |
That's a shame :/ |
Sorry, mis-usage if irony here For me it is totally inacceptable. Why ? Because if
I think @tbrand will be on the same page (thats why I ping him) What do you think about this ? Sorry again for this |
For me parsing URL with a regexp is good (I have juste noticed that regexp un What we want (for me) is routing, no matter what technic is used (regexp, or elle). However, this step SHOULD to be done as a dispatcher -> I mean handling http req to route to a spécifications code (not handling all urls in one function) PS : @OvermindDL1 |
It has quite a variety of routing interfaces, pick one? The regex one is the slowest though so if that is what you are wanting to compare... |
@OvermindDL1 could you list the routing interface ? In the case of |
@dom96 could |
More restrictive? What do you mean? You can use regex for it too if you want, but I find that a little silly. |
I come from
But perhaps there is a smarter way to do (having one place where is defined callback in use and params), feel free to share ^^ |
It has exact matching (exact string match, which most frameworks support), it has prefix matching (like how the elixir and many other frameworks primarily route on), it has regex matching (which frameworks like elixir do not support at all and you have to build it yourself), it has custom matching (supply your own matching and routing handler) that I know of off hand, and I think I'm missing one. In general the order supplied above is the efficiency that they run at (although the custom matching might be better or worse depending on what you do). Full full key processing and validation checking you use the regex matcher (which is what the evhtp benchmark is doing now).
That's essentially what evhtp is doing currently (although not |
My suggestion is surely not that much harder to read. The advantage is that it should be many times faster than resorting to Regex. |
@OvermindDL1 it's quite the case https://github.com/tbrand/which_is_the_fastest/blob/master/cpp/evhtp/main.cpp#L41 but there is not restriction @dom96 does routing could be done something like one one line ? |
@OvermindDL1 do you have time to implement custom matching if it's the fastest way to have routing, so why not having this in this project |
So what restriction are you speaking of?
That's essentially what I had originally but tbrand didn't like it and deleted ethtp entirely (wtf...) as it wasn't "built in"... >.> |
@OvermindDL1 I think a mis-understand
Could you then give me an URL (or |
This is where I did it with a combination prefix matcher and custom parser: Specifically this line:
Being the line he objected to as it was not a built-in parser/matcher, where the regex does (it stores the matched segment into argument storage inefficiently and all just as he wanted). EDIT: As a note, the above work is the exact same amount of work that a couple other frameworks (a rust one that I copied the handling of) did, so I don't know why it was not accepted nor why tbrand just removed it outright as it seemed exceedingly hypocritical (which was my whole issue with it...). |
What that does is the same as the regex, just a different syntax form of it that is more efficient as it does less work but also means the data is not in any expected form (have to validate it yourself and can't change the matcher based on the data type unlike how you can do with regex or a custom matcher). |
I don't want to bloat httpbeast with routing. Plus the code I gave you is only two lines, it's really not that much. |
@OvermindDL1 personally, I prefer the https://github.com/tbrand/which_is_the_fastest/blob/24b8f660bd2cbe1bfa80da391c4ac3d9ed264dd7/cpp/evhtp/main.cpp impl @dom96 convinced, please be my guest on |
As do I, but tbrand didn't and he deleted it all entirely outright, all in a single commit with other changes as well, thus preventing a rollback (still very wtfery there). Thus the regex implementation that lost ~10% of the performance overall based on quick tests at the time. |
@tbrand Is there any warnings about that ? |
I'll make a PR if @tbrand gives the OK :) |
Can we say that the below code has a feature of routing? if request.path.startsWith("/user/"):
let id = request.path[6 .. ^1] @dom96 You said
Yeah that's sound great! But the feature does not match to the concept of this repo. |
@tbrand For me for me it's OK to include |
@waghanza How?
This way? |
@tbrand Yep I totally agree that this writing way COULD be strange for some devs, but this code match routes :
but not /users/1. For me it is a |
@tbrand also httpbeast is on tfb https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Nim |
Hmm I don't think so. If we accept it, it means every languages level implementation can be accepted. (e.g. Crystal, Ruby, ...) |
you do not seems convinced ... @OvermindDL1 what do you think ? (I do not want to take decisions unilaterally) @dom96 for me an important point is : how we do not get out-of-sync ? |
What does that mean? Does it mean "every HTTP server implementation without a router?" To be fair, your repo is called "web frameworks" so I can understand if you don't want HttpBeast in here. But IMO you should set the bar higher. Routing is relatively trivial.
What do you mean "out-of-sync"? |
@dom96 I mean having outdated implementations of each frameworks |
It shouldn't be a big deal since you've pinned the versions. |
@dom96 If I can remind you, it will be better. I mean if codebase has to be updated, I prefer that its you (or an other |
Seems fine to me to include it, what is being tested here isn't even the languages but rather how efficient their socket and string processing capabilities are considering how little time is spent in each language proper. If you really wanted to do testing of the frameworks then you'd need to test a lot more, concurrency, websockets, etc... etc... All that is being tested here is socket handling and some simple string processing. |
of course @OvermindDL1, a I can handle work on implementations, but have no time to define a complete set of specs, if you are interested, feel free to write specs, I'll handle the coding part ;-) @dom96 for me it's OK, you can open a |
Okay, may take me a bit. Busy with a house move right now :) |
No hurry 😊 |
@dom96 ping ^^ |
heh, I still have no time for this, sorry. Happy to review PRs if you want to implement httpbeast benchmarks yourself |
I'll try |
@dom96 any time to make a |
@dom96 The parsing way is not realy important, the most important here is to have one parsing reflecting the real-word usage |
Yeah, sorry, again, I'm happy to review any PRs. It should be fairly simple for you to implement this since you know exactly what you'd like out of the benchmark. |
https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Nim/httpbeast
The text was updated successfully, but these errors were encountered: