Okay, really neat stuff. Thanks for trying this out and presenting those benchmark results! Initial thoughts:

1. I think / hope we should be able to do this without the introduction of atomics. As you've seen, they introduce a meaningful performance overhead on all operations. The scheduler should already guarantee that only one system ever has mutable access to each archetype-component (I think this is what you called a table) at once. However, we will still need to be cautious in how we implement parallel iteration over queries directly.
2. Firmly agree on the need for more benchmarks for change detection before merging something in this space. I want to have a clear sense of the performance tradeoffs involved, and the
3. We should consider making change detection configurable (Change Detection as Components / Opt-in or opt-out of Change Detection #4882) before merging this work: I suspect the correct trade-offs will vary substantially by component type.

Definitely excited to have this, as it opens up an opportunity for my reactive UI crate to skip regenerating the UI when a query has no changed data at the archetype/column level.

1. I think / hope we should be able to do this without the introduction of atomics. As you've seen, they introduce a meaningful performance overhead on all operations. The scheduler should already guarantee that only one system ever has mutable access to each archetype-component (I think this is what you called a table) at once. However, we will still need to be cautious in how we implement parallel iteration over queries directly.

current impl of this pr includes both table (built with their owned table-storage columns) and every columns (both table-storage and sparse-set-storage). schedule cannot guarantee only one mutable access to a table and sparse-set column simultaneously. If we avoid using AtomicType, the viable option would be to only implement column-level change detection specifically for table-storage columns. (of course ,i think not to use atomic is the right way that will greatly reduce overhead )

2. Firmly agree on the need for more benchmarks for change detection before merging something in this space. I want to have a clear sense of the performance tradeoffs involved, and the

yeah,i think i can add more benchmark related to change detection in another pr

The only time we need to update change ticks in parallel is when we're using par_iter. Could we special case that scenario? Maybe use something like https://docs.rs/thread_local/1.1.7/thread_local/ and take the max of all the ticks after the par_iter is done and use that to update the archetype ticks.

Also adding branching inside the iterator is very bad for vectorization. You probably want to somehow update the matched archetypes. Probably needs benchmarking to be sure.

The only time we need to update change ticks in parallel is when we're using par_iter. Could we special case that scenario? Maybe use something like https://docs.rs/thread_local/1.1.7/thread_local/ and take the max of all the ticks after the par_iter is done and use that to update the archetype ticks.

Also adding branching inside the iterator is very bad for vectorization. You probably want to somehow update the matched archetypes. Probably needs benchmarking to be sure.

yeah,this impl is just a try to identify a method that balances both ergonomics and performance.still need more benchmark,my current thoughts are:

1. archetype/table level change detection is not easy to impl in bevy,A archetype not only updates pararllel when using par_iter but also between systems run(mulityple systems can run parallel with same archetype)
2. it is not worth it that accurate update archetype/table change tick like Mut when deref_mut of each coloumn/archetype.
3. similar to flecs,we could update the archetype/column level tick when it first mutable access in a system run, for example ,Query<&mut T >.iter_mut().foreach that will update the corresponding archeype tick even if the loop does nothing;

This is a critical issue, as current change tick prevents the use of SIMD instructions and significantly reduces effective memory bandwidth. This throws ecs back to the age of even 8086, let alone compete with seriously optimzied OOP designs.

In this context, atomic operations could utilize relaxed memory ordering, since strict ordering is unnecessary—as long as system-level access to the table is already properly sequenced.
The most important consideration is to ensure that the system itself does not rely on any implicit ordering or introduce ordering bugs.

I hope this fix can be implemented soon, since having to write and read massive amounts of unnecessary data would be a rather unfortunate and inefficient outcome for everyone.

im most cases i don't even care the changed ticks. If someone wants to do the old ways why not put a Changed data component to those entities and do the ticking on their own tables. Why our fast and clean table should pay for the crazy O(n) operation.