Best way to run function many times (and output multiple data types)

Replies to This Discussion

Permalink Reply by David Rutten on July 25, 2012 at 4:12am

Hi Brian,

a sharp increase in computation time like this is indeed pretty suspect. The most important thing I've learned with regards to optimization is that thinking about it won't help. There is one thing you must always do if you're seeking to optimize code, and that is profiling.

You should add some code that measures how long it takes to perform certain subtasks of your script. That way you can narrow it down to the offending lines (or sometimes line if you're lucky) within minutes. If you're stumped by the performance of some code in my experience it's never slow where you expect it to be slow. You can use the System.Diagnostics.StopWatch class for accurate profiling, it has better accuracy than DateTime.UTCNow:

Dim profiler As New Stopwatch()

profiler.Start()

'Do something here

profiler.Stop()

Rhino.RhinoApp.WriteLine("This code took {0}ms", profiler.ElapsedMilliseconds)

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Brian Harms on July 25, 2012 at 10:36am

This is great. thanks, David, I'll give it a shot.

Permalink Reply by Brian Harms on July 25, 2012 at 2:36pm

So there are a couple things I've run into. 

The First thing is that within the single scripted component (the one that defines a function which outputs an instance of a class and then calls the function 6 times) I can only profile each function call (not what happens inside each function). Maybe because I have the function defined in the <Custom additional code> area? Keep in mind this component takes over 6 seconds to solve (according to profiler widget).

So then to test what happens in one of these functions I take the contents of one function and have it loose in runscript. The methods in the script get the component's inputs directly and there are no more functions or user-defined classes being used. In this case the component only takes 60 ms. I'm confused!

The second thing is that many times the result of the stopwatch will be something like 5ms while the profiler in GH says the component took around 60 ms. I have 

Dim profiler As New Stopwatch()

profiler.Start()

at the beginning of runscript, and

profiler.Stop()

Rhino.RhinoApp.WriteLine("This code took {0}ms", profiler.ElapsedMilliseconds)

at the very end. So all of the user-defined stuff should be getting measured within this stopwatch.

-Brian

Permalink Reply by Brian Harms on July 25, 2012 at 3:15pm

Maybe it's better to just show you. I've attached a file (disregard everything but the 2 scripted components on the right) that shows the performative difference between 2 custom scripted components that achieve the same exact thing but with different methods. The one that uses a function and returns a class instance takes 12x longer than the other. I'd like to use the function and class method so I can repeat the function multiple times in this component (right now it is only called once, just for simplicity's sake. But each additional time the function is called, the solve time increases - if 2 seconds at 1 function call, its 12 seconds at 6 function calls).

This means that unfortunately the stopwatch profiling hasn't been very helpful - because when I isolate the contents of the function to see what's slowing it down, the component only takes a tenth of a second! but when those contents are placed inside the function it goes back up to 1 or 1.2 seconds.

Hopefully someone has some insight. I'm sure there is something I'm missing or doing incorrectly.

thanks,

Brian

Permalink Reply by Brian Harms on July 25, 2012 at 3:19pm

forgot the file. Should be used with a rhino file with units set to inches.

Attachments:

• function outputting class instance_For David.gh, 33 KB

Permalink Reply by David Rutten on July 25, 2012 at 4:06pm

I'm getting NaNs out of the ArcSine component which is causing overflow errors in both scripts. Is that supposed to happen?

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Brian Harms on July 25, 2012 at 4:11pm

hmm, nope - not supposed to happen :)

The file is unit-sensitive (it actually is designed not to be - thats what I was trying to accomplish with the unit detection and object scaling. It used to work - haven't diagnosed the problem yet. 

Are you using a rhino file with units set to inches? (I forgot to mention it right when I posted, I edited the post a few minutes later - maybe it was after you had already seen it).

Permalink Reply by David Rutten on July 25, 2012 at 4:13pm

When I switch to inches it works.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on July 25, 2012 at 4:10pm

Your functions and many of your variables are not strongly typed. This is throwing compiler warnings and causing a lot of variables to be treated as System.Object, which always slows things down as it requires boxing/unboxing and typechecking at runtime. Code like this:

Class jointClass
  Public angles
  Public rotPlns
  Public curPlns
  Public corIndx
  Public limIndx
  Public fProtect
End Class

should really have As Type clauses for all of those fields:

Class jointClass
  Public angles As Double
  Public rotPlns As Plane
  Public curPlns As Plane
  Public corIndx As Integer
  Public limIndx As Integer
  Public fProtect As Boolean
End Class

or whatever type they are supposed to be.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Brian Harms on July 25, 2012 at 4:14pm

Ah ok that's helpful. If it is a list of planes should I write that here?

i.e.

 Public curPlns As list (of Plane)

?

Permalink Reply by Brian Harms on July 25, 2012 at 4:16pm

And when I define the function, should I do this as well?

i.e. 

function (a as whatever, b as list (of whatever), etc...)

?

Permalink Reply by David Rutten on July 25, 2012 at 4:21pm

Yes, most definitely. Also define the return type of the function:

Public Function SomeName(ByVal arg0 As SomeType) As SomeOtherType

I suppose I should make the VB compiler treat these omissions as errors rather than warnings, there's no way C# will let you get away with this.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

• ‹ Previous
• 1
• 2
• Next ›
• Page