speed up examples

[jasmainak]

I am quoting @ntolley from here:

I think a very necessary discussion will be which examples we are ok with using a longer dt. Especially since this PR is adding two more simulations to the pile. At the moment it is set to 0.025 ms or 40kHz which is right in line with state-of-the-art recording setups. While a larger dt may result in less accurate simulations, most (if any) of the examples will see no appreciable change. Especially for subthreshold simulations where we're only interested in 1-100 Hz oscillations (slight inaccuracies in the ODE solver may be more impactful for spiking dynamics).

We need to start thinking of strategies to speed up the examples so CircleCI doesn't run forever when we make a pull request.

Another strategy might be to add an argument prune_weights_below=1e-8 or some such thing ... not sure how much speed gains we might get from that.

Finally, we could also consider running the builds in parallel or running only the affected example etc. But these CircleCI tricks should be last resort ...

[cjayb]

I really want to agree to increasing dt, but I think we'd regret it. At least in public-facing pages. Even a factor of 2 will lead to visible changes in dipole waveforms. Do we really want to equivocate which small differences are meaningful, and which aren't? Our model outputs are highly weighted towards the spiking dynamics of the cells, not sub-threshold phenomena (this is a little counter-intuitive, and something I think about a lot).

If we want to avoid including MPI in our examples, the only alternative I can see is to have CircleCi only rebuild the examples that have changed. I suppose that would require some sort of persistence of the builds, which is unlikely to be possible...

[ntolley]

I think this has essentially been addressed, the docs take ~5 minutes to build on CircleCI which is faster than the unit tests

Feel free to reopen if you're optimistic and think things can be even better!