Meshing 
around while running some simulations (on the same machine) so no accurate meshing times, it is though 150k particles. I don’t know what the viewport to render meshing resolution formula is so it is vp of 1.0 and 555,562 faces and the render Meshing Res is set to 6.0 so whatever that works out to be. Sorry it is a monitor hog, how do you have an attachment open in a new window here?
Other plugins were harmed in the process of this test 
First off I was unable to “patiently” mesh this with Pwrapper after waiting an agonizing ten minutes. (not even with disable in viewport as a current unfixed bug that actually totally disables it) I only entertained the thought of Blobmesh (I actually did try it and had to kill process out of max after I get the settings to match reasonably close @ a way lesser frame)
I cached this system multiple way, first pFlow Disk Cache, Second save to PRT, Third exported pFlow to Realflow to get a bin sequence. All caches were stored on the same drive.
I adjusted an old script so that starts the timeslider at frame zero starts a timer then jumps to the end frame stops the timer when the step is complete…
155,424 Particles
Zhu/Bridson/Radius 3.0/RandomizeById 80%/ReleativeToMaxRadius 3.0/Blend Radius 5.0/Density Trim 0.47/Strength 21.15
Also did something change with the Relative to Max radius Value? This scene was saved in 0.6.4 and loaded into 0.9 and the viewport value was 6.0 it is now at 3.0?
A couple of numbers (in seconds):
PRT Loader (PRT)
Solo (w/ particles @ 100% vp) - 0.003, 0.001, 0.002. 0.003
+Frost (w/ 1.0 vp + particles) - 0.862, 0.85, 0.846, 0.909
PRT Loader (BIN)
Solo - 0.009, 0.01, 0.009, 0.016
+Frost - 1.225, 1.24, 1.198, 1.186
Cached Pflow
Solo - 0.128, 0.127, 0.128, 0.126
+Frost - 1.212, 1.277, 1.246, 1.28
Realfow Particle Loader (ugh)
Solo - 6.683, 6.438, 6.432, 6.455
+Frost - 7.907, 7.89, 7.863, 7.853
Max only consumed 2.23 gigs of physical memory at render res of 6.0, seems my graphics card had more trouble with it.
Thanks for the numbers!
Just a word of warning should you ever come to the point to test the RealFlow meshing. It has been reported that meshing BIN sequences saved out of Krakatoa can take significantly longer to process, possibly due to some channels that are not populated natively. So if you will be benchmarking RealFlow against Frost, please be sure to use BIN files simulated inside of RealFlow to be fair.
You most welcome 
I did try some Realfow meshing to compare too. I actually exported the PFlow system via the RF PFlow Exporter to try and get an unbiased result as possible but alas my skills in the Dark Art of Realflow meshing aren’t as good as I would want them to be to make any kind of a “fair” comparison. Not to mention when I do get a half decent as near to “optimum” mesh in RF stills takes a while being that it is only single threaded. Meshing for me has almost always been in the order of minutes and not seconds.
LOL if anything you could bank that RF users would be buying seats of Frost when they see how versatile and quick it is 
An RF port of Frost would be cool
Being fair is of course a priority, but if you are getting minutes in RF and seconds in Frost while producing approximately the same result (face count and surface), then that is a good result too
I just wanted to make sure Frost is faster than RF’s meshing so we can market it correctly.
Good post
I didn’t mean to change this. I’ll look into this so I don’t do it again by accident.
Was is an unusually long delay from your graphics card, or about what you expected?
Sorry it was actually the Render Parameter value and not the Viewport that was set to 6.0 and came back as a 3.0 in 0.9.
As for the graphics card thing I am not sure what to expect as I have seriously gotten used to seeing the white screen of aggravation across the board in max since I upgraded to win7 
I do have a reasonable card an nvidia 480GTX, not really in the mode to spend the cost of my workstation on quadro again.
I’ll have to test OpenGL, I do expect some pause with directX as the mesh is changing and dx relies heavily on mesh caching for vp speed.