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.)
