Performance benchmarks:

@quaquel Performance benchmarks provide a very clear picture of the trade-offs I've made. Here is my analysis of what’s happening:

1. The Win: Initialization Time (-10% to -22%)
   The Initalization time improved significantly across almost all grid-based models.
   Why? By removing __dict__ from millions of Cell instances, Python’s memory allocator has much less work to do. Allocation of a small, fixed-size object (slotted) is much faster than allocating an object that might eventually need a dynamic hash table.
   Verdict: This is a massive win for users setting up large simulations.

2. The Concern: Run Time Regression (+5% to +10%)
   We are seeing a noticeable regression in Run time, particularly in BoltzmannWealth (+10%) and WolfSheep (+4.8%).
   Why? The culprit is almost certainly the manual caching logic I implemented for neighborhood.
   The Bottleneck:

• Python's functools.cache is implemented in C and is extremely fast at handling arguments. My replacement creates a tuple ("get_neighborhood", radius, include_center) on every call and performs a manual dictionary lookup in pure Python.
• In models like Boltzmann Wealth, agents are constantly asking for their neighbors. The overhead of creating that tuple and the Python-level dict lookup is overriding the small speed gain provided by __slots__ attribute access.

To fix the regression, we should optimize the "hot path." In most Mesa models, radius=1 is called the vast majority of the time.

My Suggestion: Instead of a general dictionary for all radii, we can use a dedicated slot for the most common case:

• Add a _neighborhood_1 slot specifically for the radius-1 neighborhood.
• Store the CellCollection directly there.
• Only fall back to the dictionary-based cache for radii > 1.

Why this would work:

• It avoids tuple creation for radius=1.
• It keeps the memory savings of __slots__.
• It should bring the Run time back down (likely even faster than the original, since we'd be doing a simple attribute check instead of a functools.cache call).

I haven't implemented it yet but would like to give it a try. What are your thoughts?

intialization is nanoseconds, so not a major issue. The 5%-10% runtime increase is more relevant because that is in milliseconds to seconds. So, runtime is orders of magnitude more relevant.

To be clear: I am open to exploring getting rid of __dict__. However, I find the memory premise underpinning this PR not convincing. Because of this, I am also skeptical about adding more code complications just to regain the lost performance. In short, I am inclined to prefer a simple @cache and __dict__ solution, with the additional memory footprint, preferable over more code complexity and lost performance. But again: if there is an elegant solution, I am open to considering it.

Thanks for this PR. I am closing it in favor of #3113, which seems to offer a more promising direction for achieving the main aim of this PR, while also resolving interactions with #3080.