Carter Anderson

I agree that "retirement" is an extremely reasonable approach for now, especially given that the current "spawn and despawn a lot of entities frequently" behavior will put a lot of...

Yeah I do think some of these tests are flaky. I really wish we had my tests from #2062, which are generally much stabler + were very useful when I...

  I'm seeing (repeatable) notable regressions in: * simple_iter/base (~16%), which is in-line with the table iterator regression * get_component/base (~10%), which does make sense, given that we've added...

"fragmented iteration" performance is generally more important than "unfragmented iteration", so the tradeoff seems welcome. And notably, we aren't seeing a significant reduction in system iterator impls. get_component regressions are...

To me this doesn't feel clear cut. I'm guessing that the get_component regression stems from the "retirement" code (due to extra branching) and not the "niching" code. If it _does_...

I think pre-registering a system with the executor, retrieving a handle from that, then triggering a run of the system via commands (or some other abstraction) is probably the way...

To add to this: I think we should have a way to queue runs of systems (in the same stage as the queuing system or some future stage) via their...

> As far as I know there is nothing for events (yet). Yeah theres nothing that solves this problem for events yet. Some options: * Export an unbounded crossbeam channel...

Now that windows are entities, we could probably work around the crate structure issue by adding a `WindowIcon(Handle)` component to `bevy_render`. I think our current crate structure is close to...

This is even more important now that we're using bevy_ecs instead of legion. Dynamic plugin loading will be broken until we add this.