Hi Marco,
> Could you add it right now for the current version of Moi or you're
> always referring to the upcoming V4 ?
I'm referring to v4, sometime during the v4 beta period. That's when I'll be doing releases on a regular schedule and so it's easier for me to add stuff. Adding it to the current version would involve all sorts of release related work like making a new build, testing it, uploading it, updating version numbers and web pages and various stuff like that.
> But this part of your sentence puzzles me a little bit :
> "...I wouldn't really expect any performance difference from looping through them as you would do currently."
I was thinking of your example that you had specifically mentioned: "Input a "min" and "max" values that represents the range of the area that I want to search" . The way to do that is going to be to loop through all the faces, calculate the area of each one and compare it to the min and max values. In all that work 99.99% of the time will be in just the area calculations so for performance whether the loop is done in script or done in the back end API implementation doesn't make any measurable difference.
> What I want to say is this : Let's say, for example, we want to filter all closed curves.
>
> Now...one thing is to write a script that should filter all curves with getCurves() and, inside a
> loop, on each curve should call another method to check if it is opened or not.
Right, and what I was referring to would be that any filtering mechanism that I'd be able to write in a reasonable time would just be doing the same thing in the back end code. It's still useful to have such a thing but it's useful for a convenience factor of writing more concise scripts, not for performance.
> A different thing (I think) is to write a script that simply could make a call to a method named
> getclosedCurves() to get all closed curves in one single shot.
> Because, I think, in this case that method can make a direct query into the Moi's Object Model
> and not within the scripting environment.
Well, there is no such query capability existing currently. I guess one way to implement an O(1) "single shot" closed curve query would be to build an index of the closed curves inside the object list every time an object list is created, and make sure the index is updated every time the list is modified by adding or removing objects. That would indeed speed up retrieval of all closed curves from an object list at query time but the cost would be shifted to the list creation and update times instead and you'd pay that cost all the time even if retrieval of closed curves wasn't actually ever needed during the current program run.
In order to justify that cost, retrieving closed curves would need to be some kind of important bottleneck that was being frequently encountered.
Hope that makes sense!
- Michael
|