当执行大量MapReduce操作时，我希望传输的数据具有尽可能少的开销。我当前需要传递的很多东西之一是（int，float）元组。我目前正在尝试在两种传播方式之间进行选择：
序列化为字符串，例如“ 4,3.4”。如果我使用ASCII-US，我猜传输对象的大小将因此仅仅是字符串形式所需的字符数，即，如果我的整数很长或浮点数精确，则对象可能会很大。
序列化为字节数组：int使用4个字节，float使用4个字节。这样，我将始终使用8个字节。在特殊情况下，我可能较少使用字符串，但我猜想，平均而言，字符串方式会更昂贵。
因此，我目前倾向于第二种选择，尽管转换比仅序列化为字符串稍微复杂一点，但它应该更有效，对吗？
最佳答案
这是一个相当复杂的问题。
一方面，将数字从二进制转换为文本形式……然后再返回，在计算上相对昂贵。转换为十进制特别昂贵，因为转换涉及到10的重复除法/乘法。
另一方面，如果数据值（平均）较小，则文本表示在编码时可能（平均）占用较少的字节。根据网络（包括NIC，虚拟化等）的端到端速度和延迟，较小的在线表示可能会导致更大的吞吐量。
第三，如果通讯费用在总体计算中不重要，那将是没有意义的。
我的建议是：
提防过早的优化！
对环境中编码+传输+解码的两种选择（二进制和文本）进行基准测试。请确保使用典型的实际数据来执行此操作。
对整个应用程序进行基准测试。 （这假设您已经注意了第一点！）
决定二进制表示形式与文本表示形式的差异是否会对整个应用程序在真实数据上的整体性能产生重大影响。
重新编写代码...如果您的测量结果等告诉您，这是值得的。
注意：如果度量标准告诉您二进制和文本之间的差异实际上对您的应用程序很重要，则可能表明您的计算花费了太多时间进行通信和计算。值得一看的是，您是否可以减少通讯量；例如通过更改计算的粒度或正在移动的数据量。
终于...
当执行大量MapReduce操作时，我希望传输的数据具有尽可能少的开销。
这不应该是您的目标。目标实际上应该是：
使应用程序整体运行得足够快，以满足性能要求。
通过不尝试达到超出实际要求的性能来优化开发人员时间。
诸如“尽可能快”或“尽可能高效”或“尽可能小”之类的目标可能会降低工作量。您应该尝试避免它们。