What if the Grasshopper UI had an easier way to quickly ID processes intensive components?

Just a thought, seems like my definitions over the past year have really gotten slow. Its probably my increasing level of completely i ask from the program, although while waiting on my pc I wondered where the slow component might exist in the definition and if it were a mistake to be fixed, unnecessary or just a reality of the scale and scope being looked at for the definition.

Perhaps it could be located along the bottom of the window as a string of icons in a similar way as the Markov feature? Then you could see if the slow down is coming from a component not in view, rather than assuming it might be something else, such as the video card.

Replies to This Discussion

Permalink Reply by David Rutten on October 24, 2012 at 4:46pm

Hi Tyler,

it's something worth looking into, both the memory usage and processor cycles per components would be interesting to see. There are however certain complications.

Components only run when they have something to calculate. If you don't change the inputs to a component it won't recompute. So the times you see on the canvas are not all recent, in fact some may be very old indeed.

Also, a single measure of performance is always subject to a large degree of inaccuracy. Perhaps the computer was at that very moment doing some virus scanning and the extra load on the processor delayed two or three components that happened to be solving at the same time. No way to test for this without running many solutions and computing a running average.

Also, the first time a component runs it will probably take somewhat longer than usual, as methods need to be jitted. This is especially true for VB/C# components which need to be compiled to MSIL and then jitted. The first time you run one of those it may well take 1~2 seconds more than you'd otherwise get.

All this aside, it is possible to use the existing profiler data to highlight 'expensive' components so they are easy to find. It just requires a bunch of coding on my part. What I want to know is, when you figure out which components take a long time, what are you going to do about it?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Tyler Selby on October 26, 2012 at 11:43pm

Thanks for the response and explanation. Obtaining a true scientific level of control would be overkill for the motivation explained in my previous post. I was simply curious as I was testing the configuration of a set of components fairly far upstream and debated on how much time I'd save if I could quicklyfind and temporarily disable them until I settled on the data flow method that kept causing components to update.

RSS