refresh rate & profiler

A couple of related questions here:

First off, I've noticed that when using profiler as a way of streamlining my model that things that I think of as "processes" and things that I think of as "containers" often have the same (ms %) tags attached to them.

For example, I've written a little VB node that calculates and returns the area of closed curves, and then feed the results into a "Number" container which then feeds into a "Receiver" container. Clearly, the "Number" container and the "Receiver" container aren't doing as much work as the VB node, right? Well, according to their profiler tags they're doing almost exactly the same amount of work. What gives?

My question here is... are they each doing all that work? If so, I should avoid using so many "containers" and pass data along as directly as possible. If not, I shouldn't worry, but then profiler shouldn't be lying to me either.

This leads me to my next question: is there a way to see numerically how fast the whole model is updating? I'm working with some pretty hefty models here, 5mins or so for a refresh, and I'd like to see if my little efforts here and there to speed things up are working.

Thanks,

Kyle

▶ Reply to This

Replies to This Discussion

Permalink Reply by David Rutten on April 28, 2010 at 1:51am

Hi Kyle,

the profiler is a compulsive liar little pos. First of all, it doesn't actually record all time spend inside a particular component, only the time spend inside the Compute() function. Furthermore, the profiler values tend to wobble up and down a few milliseconds almost all the time, and dozens of milliseconds on components that take a long time. Whether this is due to time measuring inaccuracy or because it actually does differ between different runs I don't know (but I suspect the latter), but it does mean any single value cannot be trusted to be too accurate a representation of what's actually going on.

Also note that VB components need to be compiled, so the first profiler value after you commit the changes will be much higher than subsequent runs when the code is already compiled and cached.

Number and Receiver are doing some work. But it should be less than a Curve Area computation I'd think. It's hard to comment without knowing how this file is set up and what the profiler values are.

The Document does keep track of how long the entire solution takes, but I'm not displaying that information anywhere on the GUI at the moment. I suppose I could send messages to the status bar if the solution takes longer than -say- 5 seconds.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

ps. I recently purchased a good project profiler application, which I hope will help me track down bottlenecks in the whole of Grasshopper. I have never actually seriously investigated the code with respect to performance, but I think it's high time I start doing so...