The reason, I want instant partitioning in memory, becoz currently pflow is very slow when it comes to render high particle counts (until it becomes fast multithreaded), so maybe with low particle counts I can render pflow fast, and Krakatoa will do partitioning in memory for cached particles. (even if not many memory, it can create temporary cache files on HDD and then delete it after frame gets rendered? or can use Pagefiles?)
Partitioning of PFlow is history-dependent. It requires the whole PFlow to be simulated from the beginning.
The alternative is to have a Noise-like setup where a single PRT Loader has a modifier that is evaluated multiple times, thus producing a multiple of the same PRT file. But this is no different than cloning the PRT Loader and adding a unique Noise to each one, except for the management effort to set it up and manage multiple objects.
We are working on other alternative approaches for increasing particle counts without re-simulating PFlow, but they won’t look the same as real partitioning.