trade secrets
But seriously though, over the last 10 years I've been moving the code base in a direction that allows (1) improved robustness and THEN (2) improved performance.
With all of my recent changes to line sets in the last week, I actually didn't do a whole lot of optimization directly for the mesher in order to see this improvement.
There is still more room for more optimization and I could make it even faster; I'm just not sure (yet) that the effort will make a large dent in the overall time. Hence the reason why I want to add more performance timing meta data and then share an installer so that people, such as yourself, can do performance comparisons and let me know your performance results. This will help me help you.
Also, this performance improvement is restricted in scope. For example, if an unoptimized object is used for density interpolation then the mesher may "slow down" again.... even though it may not be the mesher per se... but the object being used. And then I'd need to look at that particular situation in depth.
I'll continue to improve all of the code in BOTH directions, with the primary focus on correctness (as I've always done) and the secondary focus on performance. Of course, I'll focus on performance in an area if/when someone raises the topic (like what you did) and for which I appreciate.
As an aside; performance is a non-functional requirement that typically can't just be "done". It needs to be baked into everything that you do and then the improvements will slowly be seen. Well, in this case... quickly seen!
That's my opinion anyway.
Kindly... Alan