Just an FYI, @cart probably don't waste time reviewing this yet ( even if you get time ) as I found some stuff that might need to change a little as I keep going. I'll mark the PR as not a draft when it's ready for review.

OK, this is still probably a little rough around the edges, but I think the concept is laid out enough to get some review by anybody who is able to look at this. If any community members want to comment on this it'd be good to get as much feedback as possible before Carter has a chance to look at him to save him some time if there are glaring issues. 😄

Hey, CI is passing now. :)

I just ran my new benchmarks on this PR and the result is ( PR in blue, master in red ):

The frame time and the CPU cycles differences are within the noise noise range on my machine ( my laptop with a web browser running on it ), but the CPU instructions are always stable pretty much within 0.01% when there are no changes so this PR clearly represents an increase of at least 1.85% increase in CPU instructions for the benchmark games. I was hoping to avoid slowing down non-scripted games, such as the current benchmark games, at all, but it looks like the new design has a slight overhead. Not sure, how much that means though.

I've now successfully demonstrated both dynamic systems and dynamic_components summing up, I think, all that is necessary to allow 3rd party implementations of scripting systems for Bevy! 🎉

The examples demonstrating both dynamic systems and dynamic components are very limited in scope and do not prove that there aren't bugs when doing queries over multiple archetypes or all kinds of other variables, but for the most part I've built on the existing Bevy logic wherever possible and there is as little new logic as possible, which should help for review and stability.

I'm going to start working on a language agnostic scripting system on top of these new features. This will stay separate from Bevy, but it will help stress test these new features once I get it going.

Awesome work! I'm curious to hear what @Ralith would think about upstreaming these changes.

I'm open to the idea, though I'd need to do a proper review. The usecase is well-justified. A few initial thoughts:

RuntimeBundle

Could this be folded into EntityBuilder?

ComponentId

Maybe a custom Hash impl that discards the enum tag could help recover some of the perf here? I'm not all that concerned about an apparently purely-on-paper overhead, though.

Could this be folded into EntityBuilder?

Oh, that's perfect. I had missed the EntityBuilder. I'll update that. I really hated the name RuntimeBundle anyway. 😛

Maybe a custom Hash impl that discards the enum tag could help recover some of the perf here?

That's a good idea, I'll try that out. I'll will add that I'm pretty sure that with these changes the ECS bench iteration speed is not decreased when using static systems.

As far as the iteration speed of dynamic systems ( or, probably more accurately, stateful queries ), the last I tried the ECS bench with a dynamic system the iteration speed when from ~1µs to ~100µ compared to the non-dynamic version. I'm not sure how accurate that benchmark was, though.

At this point I figured that we can be reasonably sure that we haven't lost a, so far, noticeable amount of performance for non-scripted systems. If we notice scripted systems, or stateful queries or something are slow, we can try to optimize it later after it is actually working, being that the non-dynamic features already there don't appear slower because of the new features.

Using a custom hash implementation and benchmarking just the hash with criterion yields a small performance increase:

hash rust id            time:   [7.2598 ns 7.3019 ns 7.3501 ns]                          
                        change: [-7.3700% -6.4855% -5.5781%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  4 (4.00%) high mild
  4 (4.00%) high severe

hash external id        time:   [7.2684 ns 7.2878 ns 7.3092 ns]                              
                        change: [-9.0916% -8.1682% -7.3739%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe

Does this look right for a hash implementation? I'm not sure if there is a better way to do this that avoids the match to avoid the branch while still making the hash of RustTypeId unique compared to ExternalId. In this case I just write an extra byte as either a 1 or a 0 to distinguish them from each-other. Maybe that one byte is smaller than the discriminate used in the derived hash implementation and that's why it's faster:

#[derive(Debug, Clone)]
pub enum ComponentId {
    RustTypeId(std::any::TypeId),
    ExternalId(u64),
}

impl Hash for ComponentId {
    fn hash<H: Hasher>(&self, state: &mut H) {
        match self {
            ComponentId::RustTypeId(id) => {
                id.hash(state);
                state.write_u8(0);
            }
            ComponentId::ExternalId(id) => {
                state.write_u64(*id);
                state.write_u8(1);
            }
        }
    }
}

Edit: Opened a forum topic just to get more feedback.

Also it doesn't effect the CPU instructions measurement noticeably for the asteroids and breakout benchmarks.

OK, I got help on the forum that said that the hashes are allowed to collide, so we can totally get rid of any discriminant between RustTypeId and ExternalId ( which is probably exactly what you were meaning @Ralith, I just didn't know that hashes were allowed to collide, so I didn't think of that ). With that optimization we get a decent speed up:

impl Hash for ComponentId {
    fn hash<H: Hasher>(&self, state: &mut H) {
        match self {
            ComponentId::RustTypeId(id) => {
                id.hash(state);
            }
            ComponentId::ExternalId(id) => {
                state.write_u64(*id);
            }
        }
    }
}

hash rust id            time:   [5.3033 ns 5.3093 ns 5.3154 ns]                          
                        change: [-33.204% -32.628% -31.900%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  1 (1.00%) low severe
  3 (3.00%) low mild
  3 (3.00%) high mild
  5 (5.00%) high severe

hash external id        time:   [4.5068 ns 4.5136 ns 4.5208 ns]                              
                        change: [-43.353% -42.849% -42.378%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 10 outliers among 100 measurements (10.00%)
  4 (4.00%) high mild
  6 (6.00%) high severe

Hey that also brings down the CPU instructions a little bit in the game benchmarks. Still a little higher, but not as much as before.

OK, I've gotten this updated with the latest Bevy changes. ( I've still got cleanup to do ) I switched back to making Fetch stateful. With the simplification of the Query iterator that came with #741 the amount of complication that stateful Fetch added was much lower thankfully. With lockless queries being implemented I didn't want to have to maintain a separate query implementation for dynamic queries so I think that the little bit of extra generics that comes with having stateful queries is worth it. This may also help us with stateful queries for order independent change detection later, too.

OK, I did the cleanup I needed to do and went over the code one more time and I think it's ready for review, now.