我正在研究C/Python中的套接字，我想知道什么是将头部从Python字典发送到客户端套接字的最有效方法。我的想法是：1.对每个头使用send调用。优点：无需分配内存。缺点：许多send调用--可能容易出错;错误管理应该相当复杂1.使用缓冲器。优点：* 一个 * send调用，错误检查变得容易得多。缺点：需要一个缓冲区：-）malloc/realloc应该相当慢，使用（太）大的缓冲区来避免realloc调用浪费内存。有什么建议给我吗？谢谢：-）
send
malloc
realloc
mrwjdhj31#
由于TCP拥塞控制的工作方式，一次发送所有数据的效率更高。（已发送但尚未确认）。TCP测量返回的确认，以计算在不造成拥塞的情况下，“空中”可以传输多少数据如果来自应用程序的数据不足以填充窗口，TCP就不能进行准确的测量，因此它将保守地缩小窗口。如果您只有几个小的头文件，并且您对send的调用是快速连续的，操作系统通常会为您缓冲数据，并在一个数据包中发送所有数据。在这种情况下，TCP拥塞控制实际上不是一个问题。但是，对send的每次调用都涉及从用户模式到内核模式的上下文切换，这会导致CPU开销。换句话说，在应用程序中进行缓冲仍然是最好的选择。（至少）有一种情况下，不使用缓冲会更好：当你的缓冲区比上下文切换开销慢的时候。如果你用Python写一个复杂的缓冲区，很可能就是这种情况。用CPython写的缓冲区会比内核中经过精细优化的缓冲区慢很多。很有可能缓冲的成本会比它给你带来的回报更高。当有疑问时，进行衡量。但有一点要注意：过早的优化是万恶之源。这里的效率差别很小。如果你还没有确定这是你的应用程序的瓶颈，那就选择让你的生活更容易的方法。你可以在以后随时改变它。
xam8gpfp2#
除非你发送的数据量真的很大，否则最好使用一个缓冲区。如果你使用几何级数来增加缓冲区的大小，分配的次数就变成了一个分摊常数，分配缓冲区的时间也随之增加。
fquxozlt3#
一个send()调用意味着到内核（操作系统中直接处理硬件的部分）的一次往返。它的单位成本大约是几百个时钟周期。这是无害的，除非你试图调用send()数百万次。通常，缓冲只是在收集到“足够的数据”时偶尔调用一次send()。“足够”并不意味着“整个消息”，而是类似于“足够的字节，这样内核往返的单位成本就小了”。根据经验，8-kB缓冲区（8192字节）通常被认为是好的。无论如何，对于所有与性能相关的问题，没有什么比实际测量更好的了。试试吧。大多数时候，没有任何实际的性能问题值得担心。
send()
3条答案
按热度按时间mrwjdhj31#
由于TCP拥塞控制的工作方式，一次发送所有数据的效率更高。（已发送但尚未确认）。TCP测量返回的确认，以计算在不造成拥塞的情况下，“空中”可以传输多少数据如果来自应用程序的数据不足以填充窗口，TCP就不能进行准确的测量，因此它将保守地缩小窗口。
如果您只有几个小的头文件，并且您对
send的调用是快速连续的，操作系统通常会为您缓冲数据，并在一个数据包中发送所有数据。在这种情况下，TCP拥塞控制实际上不是一个问题。但是，对send的每次调用都涉及从用户模式到内核模式的上下文切换，这会导致CPU开销。换句话说，在应用程序中进行缓冲仍然是最好的选择。（至少）有一种情况下，不使用缓冲会更好：当你的缓冲区比上下文切换开销慢的时候。如果你用Python写一个复杂的缓冲区，很可能就是这种情况。用CPython写的缓冲区会比内核中经过精细优化的缓冲区慢很多。很有可能缓冲的成本会比它给你带来的回报更高。
当有疑问时，进行衡量。
但有一点要注意：过早的优化是万恶之源。这里的效率差别很小。如果你还没有确定这是你的应用程序的瓶颈，那就选择让你的生活更容易的方法。你可以在以后随时改变它。
xam8gpfp2#
除非你发送的数据量真的很大，否则最好使用一个缓冲区。如果你使用几何级数来增加缓冲区的大小，分配的次数就变成了一个分摊常数，分配缓冲区的时间也随之增加。
fquxozlt3#
一个
send()调用意味着到内核（操作系统中直接处理硬件的部分）的一次往返。它的单位成本大约是几百个时钟周期。这是无害的，除非你试图调用send()数百万次。通常，缓冲只是在收集到“足够的数据”时偶尔调用一次
send()。“足够”并不意味着“整个消息”，而是类似于“足够的字节，这样内核往返的单位成本就小了”。根据经验，8-kB缓冲区（8192字节）通常被认为是好的。无论如何，对于所有与性能相关的问题，没有什么比实际测量更好的了。试试吧。大多数时候，没有任何实际的性能问题值得担心。