我们正在使用CAB事件系统在我们的应用程序中发送消息。我们有一个案例，我们发布一个消息来打开一个文件，并传递一个OpenFileArgs对象，其中包含有关该文件的数据，例如id，文件名，扩展名等。这个对象不包含在文件的实际数据字节数组中。
我们接收这些消息的代码使用数据从数据库中获取实际文件字节，并使用它执行某些操作（保存，打开等）。
我正在考虑在我们发布的数据对象中包含实际的文件字节数组，因此我们不需要再次调用数据库来获取它。我能想到的唯一问题是它可能会增加CAB事件系统使用的数据对象的大小。
使用CAB事件系统发布的对象的大小（或类似的东西，因为我知道CAB实际上已经死了）我应该关注什么？我一直在寻找有关此问题的最佳做法，但我的Google-Fu今天让我失望。
答案 0 :(得分：1)
答案取决于几个因素：
内存消耗 - 消息将持续任意时间，有意为（消息存储直到发送）或间接消息（消息存储在延迟取消引用事件内容的内容中总线，比如ConcurrentDictionary）？您需要检查邮件系统的来源以确定，并且可能需要记录内存利用率。
内存压力和GC影响 - 是字节数组的分配导致内存压力导致收集和无意中将不相关的瞬态对象推广到第2代（最终导致更多的第2代GC＆＃39; S）？无论你在哪里分配字节数组，这都是一个担心，但如果消息使这些字节数组的生根时间长于原来的数字，则会更加重要。
消息传递性能 - 消息传递系统是否正在执行某种类型的序列化，这对于大型消息来说会更慢？通常只适用于进程间或机器间消息传递，并不适用于像CAB这样的东西。
对于CAB，我认为只有＃1和＃2适用 - 如果字节数组非常大，您可能需要考虑将引用传递给流，文件句柄等。这个想法就是你不想在无意中将这些字节保留在堆上任何大量的时间（如果有的话）。另一种方法是提前预先分配一个大字节缓冲区（或它们的池），并在可能的情况下重新使用它，以避免为每条消息分配新的缓冲区。