Would be even slower without refinement, because would still calculate the whole return matrix, but then just keep d in the problem while doing the iterations.
Because the toolkit does interpolation in the third way described in this post (skip to Ctrl-F “but allowing for interpolation of”) it comes with the advantage that the exact evaluation of the return fn means you don’t have to worry that, e.g., linear interpolation will cause the model to breach the constraints (implicit finite differences does breach them occasionally), and it will also be more accurate (for given original grid), but this comes with a runtime cost.
To cut the runtimes you would need something closer to the MCA (markov chain approximation) approach where you just assume that most values of a’ are ‘not allowed’ (in continuous time models this looks like the assumption that you can at most move up/down one grid point). That is, you need an assumption that slashes the choice-space.
In short, I suspect major speed gains would need to come from some strong assumptions that hold in some models but not others, like MCA. That said, if most of the runtime is the return fn it is good odds to fall a lot over the next few years with better gpus.
The good news is that with InfHorz models the toolkit is much better at transition paths than stationary general eqm, so can get some runtime back there 