C# 字符串到字节数组的速度
因此，摆脱这个问题：
哪个是快速比较：转换。 ToInt32(stringValue)==intValue 或 stringValue==intValue.ToString()
我正在寻找存储在数据包中的网络应用程序的基本类型。
想法：
- 数据包类存储
（类型）的列表 - 将对象添加到数据包类中
- 序列化并在机器之间发送它
- 反序列化为
(type) - 将
(type)转换为您最初添加的对象的类型。
最初，我使用 strings 作为 (type)。但是，我有点怀疑，因为每次我想将 int 转换为 string 时，这似乎都是一个任务分配过程。当我以 30FPS 的速度将包含大量 uints 的数据包传送到 string 时，我希望使此过程尽可能快。
因此，我想知道 byte[] 是否是更合适的类型。在 byte[] 和 ints/strings 之间来回转换与仅从 strings 到 ints 之间来回转换的速度有多快？顺便说一句，我不会经常在网络上发送大量字符串。我将发送的几乎所有内容都是uint。
So coming off of this question:
Which is fast comparison: Convert.ToInt32(stringValue)==intValue or stringValue==intValue.ToString()
I am looking a base type for my networked application to be stored in packets.
The Idea:
- Packet class stores a
listof(type) - Add objects to the packet class
- Serialize and send it between machines
- Deserialize into
(type) - Convert
(type)into the type of object you added originally.
Originally, I was using strings as (type). However, I am a bit dubious as every time I want to convert an int to a string, it seems like a tasking process. When I am communicating packets containing lots of uints to strings at 30FPS, I would like to make this process as fast as possible.
Therefore, I was wondering if byte[] would be a more suitable type. How fast is converting back and forth between a byte[] and ints/strings vs just strings to ints? BTW, I will not be sending a lot of strings on the network very often. Almost all of what I will be sending will be uints.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果两端使用相同的程序，请尽可能使用 BinarySerialization。你担心速度；但除非这只是在本地主机上的两个进程之间进行，否则实际的连线时间（更不用说延迟）将比任何实际转换过程慢几个数量级。
当然，不要连接字符串；你会让我成为一个骗子。
您需要在这里节省的是编码时间，以及滚动您自己的序列化时出错的可能性。如果正确封装程序的数据传输部分，升级它们将很容易。尝试花费额外的时间让某些东西变得更快被称为过早优化（谷歌搜索 - 这是一个有效的论点 - 大多数）。如果它是瓶颈，请利用您的封装设计并进行更改。如果你先这样做，你就不会花费那么多额外的时间 - 但最终可能根本不会花那么多时间。
关于二进制序列化的警告。您发送的类型必须具有相同的版本和类型名称。如果您可以轻松地在两端将相同的版本投入生产，那就不用担心。如果您需要更多，或者二进制序列化太慢，请查看 FastJson，它做出了很大的承诺并且是免费的，或者类似的东西。
If you are using the same program on both ends, use BinarySerialization if possible. You are worried about speed; but unless this is just going between two processes on localhost, actual wire time, let alone latancy, will be orders of magnitude slower than any real conversion process.
Of course, don't concatenate strings; you will make a liar out of me.
The thing you need to save here is your coding time, plus the possibility of errors for rolling your own serialization. If you properly encapsulate the data transfer parts of your program, upgrading them would be easy. Trying to spend extra time making something fast is called premature optimization (google it - it's a valid argument - most of the time). If it is a bottleneck, leverage your encapsulated design, and change it. You won't spend that much extra time then if you'd done it first - but likely won't end up spending that time at all.
A warning about binary serialization. The types you are sending must be the same version and type name. If you can put the same version into production on both ends, easily, it's no worry. If you need more than this, or binaryserialization is too slow, look into FastJson, which makes big promises and is free, or something similar.
byte[] 是套接字操作的“自然”数据类型，因此这似乎很合适，ints/uints 的转换也非常快。字符串有点不同，但如果您选择平台的自然编码，这也会很快。
byte[] is the "natural" data type for socket operations, so this seems a good fit, ints/uints will be very fast to convert also. Strings are a bit different, but if you chose the natural encoding of the platform, this will be fast also.
Convert.ToInt32速度相当快，只要它不会失败。如果失败，那么您将承担巨大的抛出/捕获异常的开销。byte []与其他类型的二分法是错误的。网络将所有信息本质上以字节数组的形式传输。因此，无论是包裹在NetworkStream周围的StreamReader是将byte []转换为String，还是您自己，它还在完成。Convert.ToInt32is decently fast provided it does not fail. If it fails then you incur the overhead of a thrown/caught exception which is massive.The
byte []vs. some other type dichotomy is false. The network transports all information as -- essentially -- an array of bytes. So whether aStreamReaderwrapped around aNetworkStreamis turning thebyte []into aString, or you are yourself, it's still getting done.