If the speed goes down while the simulation is already running, then this is not the compilation issue, since it is no longer compiling files at that point. There are two main reasons why a simulation can slow down at some point: 1) your simulation is filling up the memory of your machine (in particular things like StateMonitor recording a variable for every neuron at every time step) and it therefore starts using swap space on the harddisk; 2) your simulation is generating many more spikes and therefore becomes more computationally demanding.
Regarding the thread that you quoted and the general question of running loops in standalone mode (regardless of whether the loops are over parameters or inputs): if you need to do this for many loop iterations and/or in a “programmatic” way (e.g. “if this input does not evoke any spikes, increase the firing rate and present it again”), then you are probably better off to use runtime instead of standalone mode. It is a little slower in general, but you are most likely saving a lot of time by compiling less. Also, you can make use of store/restore to reset the simulation to an initial state instead of running the simulation without input to make its variables go back to their resting state.
If you want to stay with standalone mode, then the general recommendation is to try to use the smallest number of run calls possible. You can often reduce the number quite significantly by using a combination of TimedArray and expressions referring to time. To give a rough example, instead of doing this:
stimulus_rate = [100*Hz, 200*Hz, 50*Hz, 100*Hz]
n_stimuli = len(stimulus_rate)
input_spikes = PoissonGroup(100, rates=100*Hz)
for idx in range(n_stimuli):
input_spikes.rates = stimulus_rate[idx]
run(200*ms)
input_spikes.rates = 0*Hz
run(100*ms)
you could do something like this:
stimulus = TimedArray(stimulus_rate, dt=300*ms)
input_spikes = PoissonGroup(100,
rates='stimulus(t)*int((t % 300*ms) <= 200*ms)')
run(n_stimuli*300*ms)