Don't use group names in runtime code

[thesamovar]

If we can avoid using names of groups in generated code then we can avoid some recompilations that are currently happening. We could, for example, if there were two groups with names neurongroup_3 and neurongroup_4 map _array_neurongroup_3 to _array_NeuronGroup1 and _array_neurongroup_4 to _array_NeuronGroup2 (i.e. we would look up the class name of the object pointed to, and give them a numerical index that increases from 1). Now if we ran again but it would neurongroup_5 and neurongroup_6 then it would still map to the same _array_NeuronGroup1 etc. and a recompilation wouldn't be necessary.

I think we're already not freezing constants right? #480 suggests this, but on the other hand when I run some code with an increasing number of neurons N I seem to be getting recompilations sometimes. I think it would be good to avoid this for people running parameter space searches.

[mstimberg]

I'd rather not make the link between the names in the simulation and the names in the code less clear if we can avoid it. Do you really think this is a problem in practice? If you run a simulation in a for loop, then you should only end up with two different sets of names, regardless of the total number of iterations (the second set of names because at construction time, the old objects still exist). Will this be noticeable in any real setting? The only situation where I can image that it somewhat matters would be in a jupyter notebook or a similar interactive setting.

I think we're already not freezing constants right? #480 suggests this, but on the other hand when I run some code with an increasing number of neurons N I seem to be getting recompilations sometimes.

We don't freeze constants in runtime (we do in standalone, though) -- are you sure you are not getting the recompilations due to the changed names?

[thesamovar]

Do we reuse old but now deactivated neurongroup_i names or do we just add more at the end always? I feel like I am getting more than one recompilation in a loop. I see it very clearly on the speed test that the first time I run it, for all N weave and cython are much slower for the first run than the second. If it were just two recompilations then I think that would be fine! Not ideal, but good enough.

Another solution: we can add a warning to the user if they are getting potentially unnecessary recompilations by taking the code string X and removing all names neurongroup_i to get Y say, and then counting how many different X map to each Y. If it's more than 2 then we could warn about potentially unnecessary recompilations and that the user should explicitly name the objects.

[mstimberg]

Do we reuse old but now deactivated neurongroup_i names or do we just add more at the end always? I feel like I am getting more than one recompilation in a loop. I see it very clearly on the speed test that the first time I run it, for all N weave and cython are much slower for the first run than the second. If it were just two recompilations then I think that would be fine! Not ideal, but good enough.

We definitely reuse previous names (see #216), but it is a bit worse than what I said. You'll actually get N+1 different combinations of names, where N is the number of objects of the same type. If you have code like this:

for foo in bar:
    group_1 = NeuronGroup(10, '')
    group_2 = NeuronGroup(10, '')
    run(0*ms)

Then in the first run you'll get neurongroup and neurongroup_1, and in the second run you'll get neurongroup_2 (at this point neurongroup and neurongroup_1 exist) and neurongroup (because the object of that name was already replaced by neurongroup_2), and finally you'll get neurongroup_1 and neurongroup_2, before the cycle starts again.

Actually, since we already have start_scope, how about making this reset the name cache as well?

[thesamovar]

start_scope idea is good but I think it would be ideal to have it 'just work' without the user having to know about that (otherwise it's a bit like the annoying clear(True, True) stuff from Brian 1 that we wanted to avoid in Brian ).

I have an intermediate suggestion if you don't like the name mapping one earlier. We talked about having a 'debug' mode (can't find the issue where we discussed this), which might include things like bounds checking on all array accesses, etc. We could make it so that if this debug mode is on (off by default) then it would use the original names, otherwise it would use the mapped names as above that avoided recompilation.