I’m always interested in ways to break up and improve the performance of my huge Grasshopper definitions.
I’d really like to learn more about best practices for when to choose Clusters vs. Data Input/Output vs. Hops.
Any and all insights would be appreciated 
I’m hoping Hops will become the default “best practice”, but we aren’t there yet. Bob McNeel just leaked out that this project is being worked on; we still have a ways to go before I would consider it being the default tool to go to for improving performance and breaking up definitions.
Clusters for compact parts of a definition. Worst performance but better understanding. Use a bus instead of your car.
Data input/output to import and export information. It can help to split a definition but it is not designed for that. If a road does not have space for so many cars, you prefer more lanes than having traffic lights.
Hops component to create tools. Takes longer to create but is the proper way to modulate the logic. No traffic with trains, each one in its own rail.
I plan to support internalizing definitions with Hops which would essentially make them a different way to make a cluster.
Oh I really really like that.
Being able to keep everything within one Grasshopper file is tremendously valuable.
Valuable, but not good for reuse. I need to figure out a balance for this.
Well the option to internalize Hops definitions sounds like a good balance to me.
Looking forward to seeing how this great new tool develops!
Mmm, to make it portable? or what is the reason? Do you mean to cache a reference file or store a copy in the parent document or create like a userObject file?
Mostly this would make it portable, yes.
I’m thinking of storing an absolute path, relative path, and a full copy of the referenced definition. If the the definition isn’t available by the path setting, the internalized copy could be unpacked and used.
This hasn’t been done yet and I’m open to other ideas.
Sounds good to have all the options. I also expect to be able to set properties like description, category, subcategory or icon (and hopefully more metada and even better using RDF languages) so it could be found in the components ribbon, used as a normal document, and maybe as a file as well? not sure if it is worth it.
To me what sounds better is to use URL rather than local paths, which is something that the food4rhino server could offer. It miss a private repository and a way to create invitations to private Hops definitions so that just those with that invite can run it, with an optional expiration date or by uses. If that is the case, the user should be able to upload/download to F4R from the rhino app, as if it were a cloud folder just for hops definitions. The rhino license could give limit space or a limit number of files, and to pay for more. It also could be paying creators to access the url/authorization.
It also demands a snippet manager to avoid continuing in the jungle with a machete and finally start building villages. This process library/searcher could be local and online. For example, the user rather than to come here or google to find examples of “parametric facade”, they could search there and to find all public access definitions in food4rhino about it, with a preview of its inputs and outputs. And allows to make advanced searches via webhooks.
Well maybe that’s too much for the moment, but yes please make the URL option working with a google drive shared link or any other repository.
The description field in grasshopper’s File->Document Properties is already used. If it is filled out, the hops component will display the description on the component’s tooltip. You also can set the input tooltip descriptions by setting the “prompt…” for each of the “Get xxx” inputs in the referenced definition. Icon support is being worked on.
I had URLs to definitions are working, but it looks like I broke that functionality recently. You should be able to set a definition URL like
https://github.com/mcneel/compute.rhino3d/raw/master/src/hops/definitions/SpikeyThing.gh
as the Hops path and the definition will be read from that location. I’ll get that fixed for the next release of Hops.
I just published a new version of Hops (0.4.4) that allows the path to be a URL to a definition.