It depends a bit on what you mean. You could build a 100 component grasshopper definition that creates a certain shape. Then, if you were to completely rewrite this same logic using pure DotNET programming (i.e. put all the logic as source code inside a single component), it will run faster. The reason it runs faster as DotNET compiled code is that you can take advantage of strongly typed variables. In grasshopper, data which flows into a component has to be analysed and cast into the required type, even if it already is the correct type. This is hard to understand without a firm grip on Classes and Inheritance... Basically Grasshopper has a lot of overhead to deal with. This has an impact on performance, but the impact might not be as big as you think. You'd be surprised how many lines of code a computer can execute in a millisecond.
However, "faster" does not mean the same as "fast". Faster than slow might still be quite slow. There's no way you can speed up things like Intersections, Closest-point calculations, curve divisions. These operations always use the same functions inside the Rhino core and thus they always run at exactly the same speed (yes, even when they are called from RhinoScript). -- David Rutten [email protected] Robert McNeel & Associates On Jan 26, 12:03 pm, baldino <[email protected]> wrote: > forgive my ignorance concerning .net programming, this question might > be stupid but: > is it possible that we will be able to "compile" grasshopper > definitions to stand alone plug ins, which then might run a lot > faster ? > > On Jan 26, 11:59 am, David Rutten <[email protected]> wrote: > > > Since Grasshopper is a DotNET program, it automatically has an SDK > > already. If you reference Grasshopper.rhp in any DotNET project, you > > can use the classes and functions directly. That is one of the most > > beautiful features of DotNET. > > > Some people have been writing custom components over a year ago, > > though I doubt they are still doing it. The reason I'm discouraging > > people to do this is that I'm changing the program and -very often- > > also the SDK on a day to day basis. If you decided to write your own > > component library, you might have to update it every time a new > > version of Grasshopper is released. This is not a fertile basis for > > 3rd party development. > > > However, Grasshopper has been designed from the start with custom > > plugins in mind. We won't have to 'forcefully insert' openings for 3rd > > party developers. > > > -- > > David Rutten > > [email protected] > > Robert McNeel & Associates > > > On Jan 26, 7:01 am, CAD-NY <[email protected]> wrote: > > > > What the heck, we'll wait.... > > > I wish I could use in full what ever is there already. > > > Own sdk? It's hard to keep up. > > > > On Jan 26, 12:03 am, damien_alomar <[email protected]> wrote: > > > > > David has talked about being able to have clusters be able to have > > > > that sort of functionality. Also, there's the long term potential for > > > > GH to have its own sdk for more "fully fledged" development, but its > > > > been a really long time (more than a year) since I talked to David > > > > about that...and he was in no rush to start putting that kind of stuff > > > > out there. > > > > > -Damien > > > > > On Jan 25, 10:35 pm, CAD-NY <[email protected]> wrote: > > > > > > Will it be possible one day to be able to add User-Category-Tabs to > > > > > store frequent Clusters, Multi-Components or VB objects made by the > > > > > user?
