我在LabVIEW instrument driver guidelines（第6.2节）中找到了这条评论：
如果您需要的终端数量多于建议的模式，请重新考虑VI上控件和指示器的分组。除错误输入和错误输出外，请避免使用群集来最小化终端数量。群集通常要求用户从群集中解包和重新捆绑数据。
如果美国国家仪器公司不鼓励群集，那么“重新考虑对VI的控制和指标进行分组”意味着什么呢？
我真的很喜欢使用群集，我认为他们已经改进了我的VI。我错过了什么吗？
答案 0 :(得分：9)
我认为这可能是NI文档中的错误措辞。如果有意义的话，一次性写入或读取仪器或其驱动程序中的许多不同值，则群集是适当的数据类型。您希望尝试避免用户必须读取群集中的数据的情况，以便他们可以在更改一个值的情况下将其写回。使用集群的其他良好的一般原则，当然在可分发/可重用的代码，如仪器驱动程序，是：
通过这种方式，您可以在不破坏现有代码的情况下更改群集中的内容。
答案 1 :(得分：6)
捆绑和分拆是相对简单的处理器和内存命中，因此除非您在紧密的循环中工作，否则性能不会令人担忧。
但是，当连接器窗格看起来像杂色豪猪时，许多人会开始将所有内容放入“巨型群”输入中。虽然这确实有效（暂时），但它最终会导致大量不必要的内存膨胀和调试痛苦，因为函数中不需要的东西仍会在代码中被复制。
更糟糕的是，最终可能会针对不同的VI使用不同的 megaclusters，然后需要在结构之间进行转换。
我通常认为最好的是，当输入和输出开始过度时，返回并将一个VI重构成几个，每个都有一个更小，更明确定义的函数。
答案 2 :(得分：4)
作为数据类型的群集很好。 NI令人沮丧的是将数据捆绑到集群中，其唯一目的是将数据传递给子vi。如果您有必须在众多vis（或sub-vis）之间共享的数据，那么您应该考虑使用功能全局，或者更改您的体系结构以规范化您的数据。
答案 3 :(得分：1)
正如错误输入和错误输出集群在逻辑上对数据进行分组并允许分层VI参数一样，我认为集群的使用也应遵循此模型。我同意，应该避免“超级集群”。就个人而言，作为一名前C ++开发人员，我不喜欢全局变量（尽管在某些情况下它们是不可避免的）。我写了很多明确的多线程LabVIEW代码，通过消息队列进行线程间通信。 （我想这是我的Windows开发人员的遗产。）如果没有集群或类型def，消息将几乎不可能。当然，我肯定会使用集群来减少终端上的引脚数量。我没有看到它的问题，只要它不过分并且具有逻辑意义。