[Merged by Bors] - Commands benchmarking

[NathanSWard]

Objective

• Currently the Commands and CommandQueue have no performance testing.
• As Commands are quite expensive due to the Box<dyn Command> allocated for each command, there should be perf tests for implementations that attempt to improve the performance.

Solution

• Add some benchmarking for Commands and CommandQueue.

[NathanSWard]

I'm not too happy with these current benchmarks.
However this was split apart from #2332 to reduce the scope of that PR.
If you have suggestions on better perf tests for commands, please let me know!

[TheRawMeatball]

A seeded RNG for optionally adding these components would be useful imo

[mockersf]

Looking at the benches, it feels like they test more entity spawning and component insertion than commands themselves.

Would it be interesting to add a dummy command that doesn't do much and use it in a bench?

[NathanSWard]

Looking at the benches, it feels like they test more entity spawning and component insertion than commands themselves.
Would it be interesting to add a dummy command that doesn't do much and use it in a bench?

Yep, I like this idea :)
I went ahead and added benchmarks for FakeCommands

[mockersf]

to show even more the impact of the size of the command, you could try with struct FakeCommand<T> {field: T} and run benches for each of:

• FakeCommand<()> typical empty command like spawning an entity
• FakeCommand<(u32, u32, u32)> typical small command like inserting a component
• FakeCommand<LargeStruct> typical large command like inserting a bundle

[NathanSWard]

to show even more the impact of the size of the command, you could try with struct FakeCommand {field: T} and run benches for each of:

Would the idea be to run benchmarks where you add only FakeCommand<()> N times to the command queue.
(In order words you don't mix different sized commands?)

[NathanSWard]

FakeCommand typical large command like inserting a bundle

Also by LargeStruct how large are we talking?

[mockersf]

Would the idea be to run benchmarks where you add only FakeCommand<()> N times to the command queue.

... probably? 😄

Also by LargeStruct how large are we talking?

I think you picked a good value 👍

My idea was to explore how your other pr on commands would impact various sized commands, looks like you found something interesting with 12 bytes commands!

[NathanSWard]

Ideally I'd like to merge this first, then merge #2332.
However I'll have to change one or the other because the Command trait got changed from self: Box<Self> to self

[cart]

RNG has overhead that I'm worried will get in the way of showing the actual cost of these operations. The goal of rng here is to produce "different archetype shapes", but we could almost as easily hard code these shapes, which would also give us the benefit of reproducibility.

[NathanSWard]

RNG has overhead that I'm worried will get in the way of showing the actual cost of these operations. The goal of rng here is to produce "different archetype shapes", but we could almost as easily hard code these shapes, which would also give us the benefit of reproducibility.

Hopefully with a seeded-rng this would lessen the impact of rng, however, it is still rng soo... 🤷
It's not so much to make archetype shapes, but rather to have the CommandQueue not know what type of command will be pushed to it.

However, we can achieve similar results with just a modulo inside a black_box so we should all be good :)
I went ahead and removed the rng.

[mockersf]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• markdownlint
• run-examples