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