Investigate our use of update_namespace

[mstimberg]

In Cython, we have code to update certain elements of the namespace at every time step to make sure that no outdated reference is used:

brian2/brian2/codegen/runtime/cython_rt/cython_rt.py

Lines 272 to 287 in a5862c7

	# There is one type of objects that we have to inject into the
	# namespace with their current value at each time step: dynamic
	# arrays that change in size during runs, where the size change is not
	# initiated by the template itself
	for name, var in self.variables.items():
	if isinstance(var, DynamicArrayVariable) and var.needs_reference_update:
	array_name = self.device.get_array_name(var, self.variables)
	if array_name in self.namespace:
	self.nonconstant_values.append((array_name, var.get_value))
	if f"_num{name}" in self.namespace:
	self.nonconstant_values.append((f"_num{name}", var.get_len))
	def update_namespace(self):
	# update the values of the non-constant values in the namespace
	for name, func in self.nonconstant_values:
	self.namespace[name] = func()

I need to investigate what situation could actually trigger this, i.e. why we added this in the first place. The only situation I can find off the top of my head related to this would be structural plasticity, but we do not support this, so… I'll do some historical digging in issues/git history to figure this out. In any case, it does not seem to be a situation that is encountered often, our test suite coverage indicates that no variable is ever marked as needing this update across the whole test suite.

(Discussed with @Legend101Zz in the context of #1769)

[Legend101Zz]

Hi @mstimberg — I traced this through the history a bit more carefully, and I think the runtime update_namespace() path might now be effectively unused on master.

The flag originally came in with a4828b8 (Oct 2013), specifically to support monitors, which at that point were the only dynamic arrays that could grow during a run. The reason this mattered is that each dynamic array effectively appears in the namespace in two forms:

• _dynamic_t: a direct NumPy view / raw buffer reference
• _dynamic_t_object: the Python wrapper object that owns the buffer and can resize it

If the array is resized, the underlying buffer can move in memory. In that case, the old _dynamic_t reference may point to stale memory, while _dynamic_t_object still knows where the live buffer is. So the original purpose of update_namespace() was to periodically rebind _dynamic_t from the wrapper whenever a dynamic array could resize during a run.

But then in cc15438 (Dec 2015), all three monitor types were changed to constant_size=True — effectively “pretend constant size”. From what I can tell, this was safe because the monitor templates do not rely on a previously cached namespace reference after resizing. They handle the resize themselves and then access the live buffer directly.

For example, in the NumPy monitor template, the resize happens through the owner/wrapper, and the subsequent write goes through the templated dynamic-array expression rather than relying on a stale cached reference:

_owner.resize(_new_len)
{{_dynamic_t}}[-1] = {{_clock_t}}

And in the Cython template, the same pattern is even more explicit: resize the wrapper first, then immediately fetch a fresh pointer from it before writing:

{{t_array}}_ptr.resize(_new_len)
cdef double* _t_data = {{t_array}}_ptr.get_data_ptr()
_t_data[_new_len-1] = {{_clock_t}}

So the important bit is that the template itself performs the resize-and-reload sequence in the same scope. There is no timestep-level window where a stale _dynamic_t binding needs to be refreshed by the runtime. That seems to be exactly why I guess you in 2015 change mentioned the per-timestep namespace refresh as significant overhead for Cython/weave: for monitors, the refresh no longer bought anything. #606 (comment)

Later, the rename to needs_reference_update in 9860b12 preserved the mechanism, but inverted the default to False.

What’s interesting is that after cc15438, I couldn’t find any new call site on master that opts back into this behavior (needs_reference_update=True, or previously constant_size=False). The only remaining occurrence seems to be the unit test in brian2/tests/test_variables.py, which tests the flag in isolation rather than exercising a real runtime use-case.

I also looked at possible dynamic-array candidates like Synapses. They are the obvious place where size changes might matter, but normal creation/connect operations happen between runs, so the namespace is rebuilt anyway. Structural plasticity is the only realistic future use-case I can think of, matching your earlier guess, but that is not currently supported ... so no worries for us :)

So my current reading is:

needs_reference_update=False is basically a contract saying: “this object may be backed by a dynamic array, but the generated template handles any resize itself and re-fetches the live pointer/reference when needed, so the runtime does not need to refresh the namespace every timestep.”

Given that, the per-timestep update_namespace() path in the runtime backends looks like dead code on master. Removing the flag and the associated nonconstant_values/update_namespace plumbing from numpy_rt.py, cython_rt.py, and probably cppyy_rt.py in #1769 would simplify all three backends without changing observable behavior — unless we intentionally want to keep this as a hook for a future structural-plasticity implementation or anything else :)

[mstimberg]

Many thanks for this deep dive into Brian's history 😊 This sounds very plausible and I agree that the best course of action is to remove all related code. Before doing that, I will run a few more tests and examples, just to make 100% sure that this code path is never used.

unless we intentionally want to keep this as a hook for a future structural-plasticity implementation or anything else :)

I think (hope!) structural plasticity will be coming in the not too-far future, but I think even in that case a better solution would be to trigger reference updates when needed (something like marking a reference as "dirty" after resizing the dynamic array), instead of forcing a reference update every timestep.