You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey, our projects are twinsies (nothing wrong with twinsies). I saw yours included a bench which was super duper helpful, because I honestly took for granted that this little step in processing requests might have too much impact.
That prompted me to pop my project in and become disappointed when I saw the numbers. Got them fixed, still not as fast as yours, or fast-url-parser, or ale, Fast-er enough than it was though ;)
Anywho, wanted to drop a note here because the benchmark numbers are a bit scary. To think that processing a request's query params would at best handle 22,603 ops/sec is troublesome. Looking at the bench you see that should be multiplied by urls.length or rather run for each and averaged, but glancing at the README might scare folks.
I've not used benchmark before, I'm sure it's far more accurate than my project but all the same here's the kind of numbers I got from my little ops-per-sec project, averaging out processing for each of the urls.
Ironically, we aren't just twinsies, there's a third tiny x params and it wins on speed.
The point is just you may want to see if there's a way to get an output from benchmark that reflects the number of url's being processed for each op. As, the current numbers are less than most frameworks take to process and return each request in full.
Thanks for thinking about performance. This is an area that really does need to be performant and I hadn't even given it any thought.
The text was updated successfully, but these errors were encountered:
Hey, our projects are twinsies (nothing wrong with twinsies). I saw yours included a bench which was super duper helpful, because I honestly took for granted that this little step in processing requests might have too much impact.
That prompted me to pop my project in and become disappointed when I saw the numbers. Got them fixed, still not as fast as yours, or fast-url-parser, or ale, Fast-er enough than it was though ;)
Anywho, wanted to drop a note here because the benchmark numbers are a bit scary. To think that processing a request's query params would at best handle 22,603 ops/sec is troublesome. Looking at the bench you see that should be multiplied by
urls.length
or rather run for each and averaged, but glancing at the README might scare folks.I've not used
benchmark
before, I'm sure it's far more accurate than my project but all the same here's the kind of numbers I got from my littleops-per-sec
project, averaging out processing for each of the urls.Ironically, we aren't just twinsies, there's a third tiny x params and it wins on speed.
Here's what that bench code looks like.
Anyway
The point is just you may want to see if there's a way to get an output from
benchmark
that reflects the number of url's being processed for each op. As, the current numbers are less than most frameworks take to process and return each request in full.Thanks for thinking about performance. This is an area that really does need to be performant and I hadn't even given it any thought.
The text was updated successfully, but these errors were encountered: