Anyone know if its better, performance wise, to have ten separate functions, or one function that evaluates the same code, using 10 different enumerated cases.
For example if you wanted to make functions to randomly delete subobject selections, would you have one function with a parameter to choose the subobject selection, or would you have separate functions for each? Is there any performance hit at all using if, then, statements for each case? Or should I worry about the load time for a large library of functions, even if they’re in structs?
deleting any actual scene object/sub-object will be many orders of magnitude more expensive than evaulating an if statement. Unless you’re in a loop running millions of times I wouldn’t worry about it.
Anyone know if its better, performance wise, to have ten separate functions, or one function that evaluates the same code, using 10 different enumerated cases.
depends how you handle the ten separate functions, if you use them as a variable which is “pre chosen” then there is a performance gain. but if they are being still being called using case or if statements then inline probably has the edge.
Thanks for the replies. I guess it does depend on what I’m using the functions for. I’m starting to get a larger and larger library of functions, where each type of function has multiple subobject versions, such as getting vertex, edge, and face positions or getting random selections, or copying selections. Most of the functions will be assigned specifically, to the current subobject level, so it seems like it would be better to keep them seperated. Others could still be used from different levels, such as my own selection conversion functions.
The main reason I'm thinking about combining functions, is that using -
fn RandomSelectionPoly SO:subobjectlevel =
(
if (SO == 1) then () else
if (SO == 2) then () else
if (SO == 4) then ()
)
looks easier to manage in large function libraries than -
fn RandomSelectionPolyVert =
()
fn RandomSelectionPolyEdge =
()
fn RandomSelectionPolyFace =
()
If I kept with separate functions I would probably want to have them in a struct. I guess the question is, how do you manage your function libraries?
You can use the case statement:
fn RandomSelectionPoly SO:subobjectlevel =
(
case SO of
(
1: ()
2: ()
4: ()
)
)
Maybe the best practice is to use the struct.
Yeah I’ve seen that method before, is that more efficient than if statements? I’ll probably just keep with separate functions in structs. Its nice having a function that does everything, but I fell more comfortable, when its used a lot in other functions, that its more efficient and less “bulky”.
let’s look at this task: “We need mechanism to be able collect most of primitive objects…”
let’s we care just about Box, Sphere, Cylinder, Cone, and Torus
solution #1 MORE FUNCTIONS
fn collectBoxes = for obj in Geometry where classof obj == Box collect obj
fn collectSpheres = for obj in Geometry where classof obj == Sphere collect obj
fn collectCylinders = for obj in Geometry where classof obj == Cylinder collect obj
fn collectCones = for obj in Geometry where classof obj == Cone collect obj
fn collectToruses = for obj in Geometry where classof obj == Torus collect obj
solution #2 MORE ENUMS
fn collectPrimitives class: = case class of
(
Box: for obj in Geometry where classof obj == Box collect obj
Sphere: for obj in Geometry where classof obj == Sphere collect obj
Cylinder: for obj in Geometry where classof obj == Cylinder collect obj
Cone: for obj in Geometry where classof obj == Cone collect obj
Torus: for obj in Geometry where classof obj == Torus collect obj
default: #()
)
it’s same ugly as the fist one.
solution #3 MORE SKILL USE
fn collectPrimitivesByClass class: =
(
for obj in Geometry where classof obj == class collect obj
)
what is better?
solution #3 is not always applicable as different sub-objects have different functions sometimes with different signature, it’s not as easily replaceable as a class name. Somewhere along the line you will have a switch clause.
yes… i’ve shown very simple sample but we can pass a concision function with number of params:
for example
delete objects
bb = for k=1 to 10 collect
(
box pos:[0,0,random -20 20] height:1 wirecolor:(#(red,green,blue,orange)[random 1 4])
)
fn findbycondition list condition params: =
(
for element in list where (condition element params:params) collect element
)
fn colorcondition node params: =
(
if params == unsupplied do params = red
node.wirecolor == params
)
fn heightcondition node params: =
(
if params == unsupplied do params = #(-1e9,1e9)
node.pos.z >= params[1] and node.pos.z <= params[2]
)
findbycondition (objects as array) colorcondition params:green
findbycondition (objects as array) heightcondition params:#(-2,8)
I agree, because some of the function I have, have more subobject types than others. With the random selection functions, you could make a function to randomly select borders or elements, or you could randomly select objects. With a function set for getting positions, you would probably only want to have verts, edges, faces, and nodes.
Although a lot of functions, you could probably use seperate functions to convert between other subobject levels, which is what I’m also considering doing, a lot of the functions I’m making for borders and elements require specific code. Functions for nodes often require different code as well.
in my library i also have search by collection of conditions…