代理服务器的 C# 性能（与 C++ 相比）
我想创建一个简单的http代理服务器，对http标头进行一些非常基本的处理（即如果标头x == y，则执行z）。 服务器可能需要支持数百个用户。 我可以用 C#（非常简单）或 C++（更难）编写服务器。 但是，C# 版本的性能是否与 C++ 版本一样好？ 如果不是，性能差异是否足够大以至于用 C# 编写它没有意义？
I want to create a simple http proxy server that does some very basic processing on the http headers (i.e. if header x == y, do z). The server may need to support hundreds of users. I can write the server in C# (pretty easy) or c++ (much harder). However, would a C# version have as good of performance as a C++ version? If not, would the difference in performance be big enough that it would not make sense to write it in C#?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您的 http 服务器将在专用计算机上运行吗？ 如果是，我会建议选择 C#（如果它对您来说更容易）。 如果您需要在同一台计算机上运行其他应用程序，则需要考虑应用程序的内存占用以及 GC 将在“随机”时间运行的事实。
Is your http server going to run on a dedicated machine? If yes, I would say go with C# if it is easier for you. If you need to run other applications on the same machine, you'll need to take into account the memory footprint of your application and the fact that GC will run at "random" times.
您描述的代理服务器主要处理字符串数据，我认为用 C# 实现是合理的。 在您的示例中，
最慢的部分实际上可能正在执行“z”是什么，无论使用哪种语言，您都必须完成该工作。
The proxy server you describe would deal mostly with string data and I think its reasonable to implement in C#. In your example,
the slowest part might actually be doing whatever 'z' is and you'll have to do that work regardless of the language.
根据我的经验，设计和实现与性能的关系远大于语言/框架的选择（但是，通常的注意事项适用：例如，不要用 C# 或 java 编写设备驱动程序）。
我会毫不犹豫地使用托管语言（无论是 Java、C# 等）编写您描述的程序类型。 如今，使用较低级语言（就与硬件的接近程度而言）获得的性能提升通常很容易被托管环境的运行时能力所抵消。 当然，这是来自 C#/python 开发人员，所以我并不完全公正......
In my experience, the design and implementation has much more to do with performance than do the choice of language/framework (however, the usual caveats apply: eg, don't write a device driver in C# or java).
I wouldn't think twice about writing the type of program you describe in a managed language (be it Java, C#, etc). These days, the performance gains you get from using a lower level language (in terms of closeness to hardware) is often easily offset by the runtime abilities of a managed environment. Of course this is coming from a C#/python developer so I'm not exactly unbiased...
如果您需要快速且可靠的代理服务器，尝试一些已经存在的代理服务器可能是有意义的。 但如果您有需要的自定义功能，那么您可能必须构建自己的功能。 您可能想要收集有关预期负载的更多信息：数百个用户可能每分钟几个请求或每秒一百个请求。
假设您需要在一台机器上提供低于或大约 200 qps 的服务，C# 应该可以轻松满足您的需求 - 即使是已知速度慢的语言（例如 Ruby）也可以轻松地每秒发出数百个请求。
除了性能之外，还有其他原因选择C#，例如，用C++ 比C# 更容易编写缓冲区溢出。
If you need a fast and reliable proxy server, it might make sense to try some of those that already exist. But if you have custom features that are required, then you may have to build your own. You may want to collect some more information on the expected load: hundreds of users might be a few requests a minute or a hundred requests a second.
Assuming you need to serve under or around 200 qps on a single machine, C# should easily meet your needs -- even languages known for being slow (e.g. Ruby) can easily pump out a few hundred requests a second.
Aside from performance, there are other reasons to choose C#, e.g. it's much easier to write buffer overflows in C++ than C#.
我希望 C# 版本几乎与 C++ 版本一样快，但内存占用更小。
在某些情况下，与非优化的 C++ 相比，托管代码实际上要快得多，并且使用的内存更少。 如果由专家编写，C++ 代码可能会更快，但很少证明这种努力是值得的。
附带说明一下，我记得 Michael Kaplan (c#) 和 Raymond Chan (C++) 在博客圈中进行过一次性能“竞赛”，目的是编写一个程序，该程序执行完全相同的操作。 Raymond Chan（乔尔）被认为是世界上最好的程序员之一，经过长期努力重写大部分代码后，成功编写了更快的 C++。
I would expect the C# version to be nearly as fast as the C++ one but with smaller memory footprint.
In some cases managed code is actually a LOT faster and uses less memory compared to non optimized C++. C++ code can be faster if written by expert, but it rarely justifies the effort.
As a side note I can recall a performance "competition" in the blogosphere between Michael Kaplan (c#) and Raymond Chan (C++) to write a program, that does exactly the same thing. Raymond Chan, who is considered one of the best programmers in the world (Joel) succeeded to write faster C++ after a long struggle rewriting most of the code.
为什么您期望 C++ 应用程序具有更高的性能？
当您做得正确时，C# 应用程序不会增加固有的速度减慢。 （不要太多删除的引用、每次调用时频繁创建/删除对象等）
C++ 应用程序真正优于等效 C# 应用程序的唯一时间是当您可以执行（非常）低级操作时。 例如，转换原始内存指针、内联汇编器等。C
++ 编译器可能更擅长创建快速代码，但大多数情况下这在大多数应用程序中都被浪费了。 如果您的应用程序确实有一部分必须快得令人眼花缭乱，请尝试为该热点编写 C 调用。
只有当系统的大部分运行速度太慢时，您才应该考虑用 C/C++ 编写它。 但有许多陷阱可能会降低 C++ 代码的性能。
（TLDR：C++ 专家可能会像 C# 专家一样创建“更快”的代码，但平庸的 C++ 程序员可能会创建比平庸的 C# 程序员慢的代码）
Why do you expect a much higher performance from the C++ application?
There is no inherent slowdown added by a C# application when you are doing it right. (not too many dropped references, frequent object creation/dropping per call, etc.)
The only time a C++ application really outperforms an equivalent C# application is when you can do (very) low level operations. E.g. casting raw memory pointers, inline assembler, etc.
The C++ compiler may be better at creating fast code, but mostly this is wasted in most applications. If you do really have a part of your application that must be blindingly fast, try writing a C call for that hot spot.
Only if most of the system behaves too slowly you should consider writing it in C/C++. But there are many pitfalls that may kill your performance in your C++ code.
(TLDR: A C++ expert may create 'faster' code as an C# expert, but a mediocre C++ programmer may create slower code than mediocre C# one)
您可以在关键瓶颈点使用不安全 C# 代码和指针，以使其运行得更快。 它们的行为很像 C++ 代码，我相信它的执行速度一样快。
但大多数时候，C# 已经通过 JIT 实现了超快，我不相信会像大家所说的那样有太大差异。
但您可能需要考虑的一件事是：与在 C++ 中有效使用指针相比，托管代码 (C#) 字符串操作相当慢。C++ 指针的优化技巧比 CLR 字符串的优化技巧更多。
我想我以前做过一些基准测试，但不记得我把它们放在哪里了。
You can use unsafe C# code and pointers in critical bottleneck points to make it run faster. Those behave much like C++ code and I believe it executes as fast.
But most of the time, C# is JIT-ted to uber-fast already, I don't believe there will be much differences as with what everyone has said.
But one thing you might want to consider is: Managed code (C#) string operations are rather slow compared to using pointers effectively in C++. There are more optimization tricks with C++ pointers than with CLR strings.
I think I have done some benchmarks before, but can't remember where I've put them.