Httparsed - fast native dlang HTTP 1.x message header parser
Adam D. Ruppe
destructionator at gmail.com
Tue Dec 15 15:08:55 UTC 2020
On Tuesday, 15 December 2020 at 10:04:42 UTC, tchaloupka wrote:
> But if these benchmarks helps Adam to make some incremental
> improvements it's a plus and many of that can be pretty low
> hanging fruit.
Yeah, I think the biggest benefit to changing this around is to
just avoid creating unnecessary garbage.
On the individual item, it doesn't really matter, but it can
build up to a totally wasted collection cycle as time goes on.
Just on the other hand, in any non-trivial real world application
there's likely to be some garbage generated anyway and this will
disappear into the noise.
Though in the hello world benches it could bring the "max" column
down since I'm p sure that is caused by a GC cycle and hello
world can potentially avoid having even one :P
> That means that with a performant parser, arsd could go up to
> around 27548 RPS -> not much of a difference that would be
> worth the hassle..
Yeah, that one is basically entirely the result of the thread
work queue. If everything else was perfect, the thread stuff
would still dominate. (My evidence for this is the hybrid and
process dispatchers doing pretty consistently better. The thread
one though is simple and cross-platform which is nice - like
without it, that Mac version probably wouldn't have worked at all
since I've written no mac-specific code in this module.)
More information about the Digitalmars-d-announce
mailing list