With both the examples in your file I think a bottleneck is generating and passing the huge list of all grid points and values before the isosurfacing component. It would be interesting to compare this with putting the noise generation method inside the Evaluate function, like the example in the first post of this thread.
(also when the field evaluation only happens once upstream, it means the component cannot make use of it for calculating the normals)
Noise is also relatively cheap to generate - for most of the things I’d like to use this for, such as functions using a lot of calls to trig functions like for triply periodic minimal surfaces, evaluating the function at the points is where the majority of the time is spent, and having to generate all these values upstream is much much slower - over 10 seconds for the gyroid example above with Millipede, compared to only 66 milliseconds with this script.
I think what would be even nicer would be to make the Evaluate method part of an interface, so you could have upstream components which define a field (without having to actually provide millions of samples of it) then pass them to the solver which then call this Evaluate method only as needed.
You could also have methods for adding, subtracting and blending them (like this and this).
This could also make it possible to use hierarchical methods in the contouring, where you subdivide cells to a finer resolution only when you know the surface passes through them, to avoid evaluating the field in so many places where it isn’t needed.
Dendro does a lot of this and is super fast, but what I still miss there is the possibility to define completely custom fields or mathematical functions.