C# Performance MS verse Mono 问题答案

【问题标题】：C# Performance MS verse Mono ProblemsC# Performance MS verse Mono 问题
【发布时间】：2014-03-24 01:36:43
【问题描述】：

我正在从事一个相当简单的（学校）项目。这是一个工作车间调度程序。它是单线程的，它的文件 I/O 非常有限（它会读取一个小问题描述，然后开始尝试构建解决方案）。 CPU应该是瓶颈。没有用户输入/GUI。

在我的机器上，在发布模式下，没有调试器 - 在 3 分钟的 CPU 时间内，我的电脑可以针对特定问题生成/评估 20,000 个不同的时间表。

在类似的 *nix 机器上，使用 mono 执行，在 3 分钟的 CPU 时间内，服务器设法生成/评估 2,000 个不同的调度。 速度是原来的 1/10。我比较了我的机器和这个特定服务器之间的 Python 性能，吞吐量几乎相同。

我认为唯一不同的“系统”调用是调用

Process.GetCurrentProcess().TotalProcessorTime.Minutes

但删除它并没有任何影响。

我尝试过使用

--aot -O=全部

它没有任何明显的影响。

我也尝试针对它运行单声道分析器，但结果并没有我希望的那么有用。

  Hits      % Method name
 57542  37.45 /usr/bin/mono
 11432   7.44 __lll_unlock_wake                    in /lib64/libpthread.so.0
  6898   4.49 System.Linq.Enumerable:Any<jobshop2.JobTask> (System.Collections.Generic.IEnumerable`1<jobshop2.JobTask>,System.Func`2<jobshop2.JobTask, bool>)
  6857   4.46 System.Collections.Generic.List`1/Enumerator<jobshop2.JobTask>:MoveNext ()
  3582   2.33 pthread_cond_wait@@GLIBC_2.3.2       in /lib64/libpthread.so.0
  2719   1.77 __lll_lock_wait                      in /lib64/libpthread.so.0

在前六行中 - 我只承认其中两行是我可以改进的“我的代码”。在完整的输出中，我可以在 /lib64/libpthread.so.0 中看到很多调用，它们似乎处理锁定、解锁、等待、互斥锁和 pthread。我对此感到困惑，因为它不是多线程应用程序。

我正在浏览单声道网站上的“性能”页面，但没有什么真正让我觉得有问题。我毫不怀疑我的代码又丑又慢，但我真的没想到性能会出现如此大的下降。我目前正在尝试在我的桌面上安装 Linux，以便我可以在同一硬件上以单声道运行我的应用程序，以帮助消除该变量 - 但我认为有人可以提供一些建议/见解。

编辑：它是 2.10.8 单声道版

Mono JIT compiler version 2.10.8 (tarball Sat Feb 16 11:51:56 UTC 2013)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          debugger softdebug
        LLVM:          supported, not enabled.
        GC:            Included Boehm (with typed GC and Parallel Mark)

【问题讨论】：

请注意，Minutes 为您提供从 0 到 59 的分钟数。之后它会换行。可能是与问题无关的错误。
也许这个SO answer 可以（间接地）给你一些关于这个问题的更多见解。
什么版本的单声道？你试过full-aot吗？
也看看内存。上次我检查时，Mono 的垃圾收集器不如 Microsoft 的好。不必要的分配可能是问题所在。 GC 与代码并行运行，也许这解释了在 libpthread 中花费的时间？
您是否在不同的硬件上进行测试？ comparable 在您的问题中是什么意思？此外，此时版本2.10 已有多年历史。为什么不使用更新的 3.x 构建？

标签： c# .net performance mono

【解决方案1】：

这是一个有点尴尬的答案，但我觉得这是最公平的处理方式......我无法真正解释原因是什么，但我不想暗示 mono 是非常慢（实际上不是）。

我关心的是让程序在服务器上快速运行。正如其他人所指出的，服务器上安装的 mono 版本非常旧。我希望没有人看到我的问题并认为它反映了单声道的当前状态。很遗憾，我无法在服务器上更新 mono 的版本。

因此，我重新编写了代码以删除不必要的计算、避免使用迭代器并限制内存分配。我的原始代码做了很多不必要的对象创建，并且对象比它们需要的大得多。清理使我的机器上的速度翻了一番，并使“服务器”性能大约是我自己的 70%（巨大改进！）。

不过，比较不同的硬件是不公平的——即使以前的 Python 程序“似乎”以大致相同的速度运行。我安装了 Linux，并且安装了最新版本的 mono，我修改后的程序运行在 Windows 版本的 96%。

我没有继续挖掘。在相同的硬件上使用当前版本的单声道，给了我几乎相同的性能。感谢您的所有建议，这非常有帮助，并为我节省了很多时间。

【讨论】：

我经常注意到这种现象，尤其是使用python。很高兴它对你有效。优化代码确实是保证性能的最佳方式——也许不是在汇编级别，但仍然可以避免不必要的工作。

【解决方案2】：

可能是内存泄漏。 Mono 正在打一场艰苦的战斗；微软制造了一个系统，开发人员不得不对其大部分进行逆向工程。如果你实在想不通，我会尝试向单声道开发者报告这个错误：

Bugs - Mono (http://www.mono-project.com/Bugs)

首先确保您的单声道版本是最新的； 2.10是古老的。截至目前，3.2.6 是最新的。来自包维护者的打包版本可能不够好；在报告错误之前，尝试从 the source tarball 构建它，并使用它来运行您的程序。

如果您在 linux 上使用 wine-mono 或类似的东西，请确保 wine 和 wine-mono 也是最新的。

【讨论】：