unity监视面板_监视Unity性能，第一部分

最新推荐文章于 2024-09-10 22:14:53 发布

culiao6493

最新推荐文章于 2024-09-10 22:14:53 发布

阅读量890

点赞数

文章标签： python java 人工智能深度学习大数据

原文链接：https://blogs.unity3d.com/2013/12/30/monitoring-unity-performance-part-i/

版权

unity监视面板

Hello! My name is Sakari Pitkänen. I work as a developer on the Toolsmiths Team here at Unity. In this blogpost I will tell you about how we do automated performance monitoring of the Unity development branches.

你好！我叫SakariPitkänen。我在Unity的Toolsmiths团队担任开发人员。在这篇博客中，我将向您介绍我们如何对Unity开发分支进行自动性能监控。

With an ever increasing amount of test configurations (platforms, operating systems, versions) it gets increasingly difficult to keep track of everything that is going on. We need visibility, and to get this we need data. Our main reason for getting performance data from Unity is to prevent performance regressions.

随着测试配置(平台，操作系统，版本)数量的不断增加，跟踪所有正在发生的事情变得越来越困难。我们需要可见性，而要获得这一点，我们需要数据。我们从Unity获取性能数据的主要原因是为了防止性能下降。

Finding performance regressions

查找性能回归

As we do day-to-day development we are not likely to notice if performance is degrading as time goes by, which is a big problem. We want to always try to make the next version of Unity perform better than the current one – and we definitely don’t want anything to be slower without us noticing it.

在我们进行日常开发时，我们不太可能注意到性能是否会随着时间的流逝而降低，这是一个大问题。我们总是希望使Unity的下一个版本比当前的版本更好-并且，我们一定不希望任何事情变慢都不会引起我们的注意。

Most of our current performance tests measure time over some specific functionality of Unity. For example we can measure the frame time over some number of frames when utilizing a specific rendering functionality. The tests are designed to look for regressions, so the measurements are implemented in a way that whenever the measurement increases significantly we have a performance regression. Each time we run a test, we run it many times and use the median value of the samples, so that a single bad sample won’t show up as a regression. Besides time we can measure other things like memory usage.

我们当前的大多数性能测试都是通过Unity某些特定功能来衡量时间的。例如，当使用特定的渲染功能时，我们可以在一定数量的帧上测量帧时间。这些测试旨在寻找回归，因此以某种方式实施度量，以便只要度量显着增加，我们就可以进行性能回归。每次运行测试时，我们都会运行多次并使用样本的中值，这样单个不良样本就不会显示为回归。除了时间，我们还可以衡量其他方面，例如内存使用情况。

Before we dig into the details of how we do this, let’s look at a concrete example: How we found a performance regression and used our data points to verify that it got fixed.

在深入研究如何执行此操作的细节之前，让我们看一个具体的示例：如何找到性能回归并使用我们的数据点来验证它是否已修复。

Performance regression and fix

性能回归和修复

In Unity version 4.3.0 we had a performance regression that affected a specific platform, Windows Standalone. Below is a table that has results for a limited set of tests run on four different platforms and two versions of Unity, 4.2 and 4.3. For all of these tests, the values are median values of measured frame times in milliseconds. The table is not showing performance per se; instead it lists the sample values. This means that increase in a measurement value can be considered a performance regression (red) and decrease can be considered an improvement (green).

在Unity版本4.3.0中，我们进行了性能下降，从而影响了特定的平台Windows Standalone。下表列出了在四个不同平台和两个版本的Unity 4.2和4.3上运行的一组有限测试的结果。对于所有这些测试，这些值都是以毫秒为单位的测量帧时间的中值。该表本身未显示性能；而是列出示例值。这意味着可以将测量值的增加视为性能下降(红色)，将减少的值可以视为改善(绿色)。

Performance test results for Unity 4.3.0

The results show that the Windows Standalone platform has a significant performance regression that affects most of the selected tests. From the test names one can already assume the cause of the regression is probably graphics related. Unfortunately, we were still working on the test rig when 4.3.0 was released, so we didn’t get the data to catch this before shipping. That will surely not happen next time, and as we widen the coverage with more configurations we expect to significantly reduce the risk of shipping with performance regressions moving forward.

结果表明，Windows Standalone平台具有显着的性能下降，这会影响大多数选定的测试。从测试名称可以已经假定回归的原因可能与图形有关。不幸的是，当4.3.0发布时，我们仍在测试平台上，因此在交付之前我们没有得到捕获此数据的数据。下次肯定不会发生这种情况，随着我们通过更多配置扩大覆盖范围，随着性能下降，我们有望显着降低发货风险。

We did find the cause for this particular regression and promptly fixed it for Unity version 4.3.1. Then we ran the tests again, now comparing last three released versions of Unity, 4.2, 4.3.0 and 4.3.1.

我们确实找到了导致这种特定回归的原因，并立即针对Unity版本4.3.1进行了修复。然后我们再次运行测试，现在比较Unity的最后三个发行版4.2、4.3.0和4.3.1。