I am actually rather surprised to see that casting a User Text Point value to a point parameter for 24 points is computationally so expensive. Let this sink in, casting 24 points as text to a point parameter may take up to 9% of the time of my entire script to compute!
At the same time, performing multiple text based manipulations and creating a point from these is much, much faster.
I’m only using User Textto store a point per object to later perform matching with between the objects in Rhino and Grasshopper to update User Text attribute values in case of changes in the document.
Technically you are not casting, but parsing. But sure, it appears a bit too slow. I might be related to an internal exception being thrown or by covering multiple other cases of conversion. It likely does more than you do here. Dealing with Culture, different strings etc.
Nevertheless, implicit type conversion (casting, parsing etc) in Grasshopper is evil in my opinion. I think it only makes sense to use it during proof-of-concept. But in general it should be avoided. A string is not a point and a dedicated conversion component would be a better solution. Anyway it is like it is. If you run into performance issues, I think a custom solution is inevitable anyways.
