No, you linked to DP5(), a 5th order method. DP8 is the 8-5-3 method of dop853 (the tableau isn’t really accessible anywhere… the dop853 code is the best reference on it). I presume that your 8th order method instead matches ExplicitRK(constructDormandPrince8_64bit()) exactly: it’s what you’d get if you search for an 8th order Dormand-Prince tableau, but it’s surprisingly not the one actually used in practice in the dop853 code.
However, that all shouldn’t matter because the peak memory should be dominated by the saving procedure if you’re using a small enough dt.
DP8 requires 29 cache vectors and so if you’re saving like 100 steps then the saving behavior is going to dominate the memory usage. (That could be chopped down with checks to calck for when dense output is unused, but only by a little).
So there’s two possible things here. One is that dt is relatively large and the integrator memory is dominating. If that’s the case, then DP8 is just the wrong choice here, and Vern7 or Vern8 is just better while being less memory intensive.
20 cache vectors for that. The Dormand-Prince 6/8 method only requires 15 cache vectors, but it would be more efficient to just use Vern7 for that same memory usage. You can check this by running Tsit5() or DP5(), which will match the Wikipedia link in memory and so if that’s what you actually implemented then it should be fine.
The other possibility is that dt is small and thus the solution itself is dominating memory, in which case I’d want to see if your current solve call is chopping everything out.