我使用C#和32feet (版本3.5)通过蓝牙(SPP)发送250个字节的块到我目前正在为其编写固件的嵌入式设备。
我使用以下代码设置我的连接:
var client = new BluetoothClient();
client.Encrypt = true;
client.Connect(bluetoothAddress, ServiceClassId);
NetworkStream stream = client.GetStream();
var writer = new BinaryWriter(stream);我遇到了一些吞吐量很低的问题,每个块使用以下代码传输大约100 ms:
public void SendData(List<byte> data)
{
try
{
foreach (byte d in data)
{
writer.Write(d);
}
writer.Flush();
}
catch (Exception)
{
// The connection was lost
ConnectionCleanup();
}
}在将上面的代码块更改为下面的代码之后,每个块在4ms内传输。
try
{
writer.Write(data.ToArray());
writer.Flush();
}
catch (Exception)
{
// The connection was lost
ConnectionCleanup();
}我很难理解这种“简单”的代码更改如何会对吞吐量产生如此大的影响。有人能帮我解释一下发生了什么吗?我想这跟32英尺的潜在机制有关吧?
我反复修改了代码,每次结果都是一样的。所传输的数据也是相同的。
我还直接从Windows连接到设备,然后在Realterm中打开COM端口发送相同的数据。在本例中,我获得了与使用writer.Write(data.ToArray())类似的吞吐量。
我正在使用Microsoft Bluetooth Stack。
发布于 2016-03-31 19:52:28
看看参考源 for BinaryWriter,Write(byte)调用底层流的WriteByte(byte),Write(byte[])调用Write(byte[], int, int)。进一步看,我们看到NetworkStream没有覆盖虚拟方法WriteByte,因此使用了基本实现:
// Writes one byte from the stream by calling Write(byte[], int, int).
// This implementation does not perform well because it allocates a new
// byte[] each time you call it, and should be overridden by any
// subclass that maintains an internal buffer. Then, it can help perf
// significantly for people who are writing one byte at a time.
public virtual void WriteByte(byte value)
{
byte[] oneByteArray = new byte[1];
oneByteArray[0] = value;
Write(oneByteArray, 0, 1);
}而且,NetworkStream没有内部缓冲区,它只是将写调用传递给底层Socket。在第一种情况下,您正在进行250次网络呼叫,在第二种情况下,您正在进行1次网络呼叫,因此,性能差异的原因应该是显而易见的。
https://stackoverflow.com/questions/36341540
复制相似问题