python - Win32 事件循环似乎是程序瓶颈

Question

我正在用 Pyglet 用 Python 制作一个游戏。我刚刚完成显示部分，并遇到速度问题。像一个好人一样，我进行了分析，并得到了以下内容:(排除了无趣的部分；目前，当我按下带有随机洋红色和白色的箭头键时，它只是重新绘制屏幕)

    15085326 function calls (15085306 primitive calls) in 32.166 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000   32.168   32.168 <string>:1(<module>)

   120139    0.499    0.000    0.686    0.000 allocation.py:132(alloc)
   120121    0.563    0.000    0.844    0.000 allocation.py:268(dealloc)

       99    0.743    0.008   20.531    0.207 engine.py:58(Update)

   237600    0.796    0.000   11.995    0.000 sprite.py:349(_set_texture)
   120121    0.677    0.000    9.062    0.000 sprite.py:365(_create_vertex_list)
   357721    1.487    0.000    3.478    0.000 sprite.py:377(_update_position)

   420767    0.786    0.000    2.054    0.000 vertexbuffer.py:421(get_region)
   715442    0.859    0.000    1.280    0.000 vertexbuffer.py:467(invalidate)


        1    9.674    9.674   32.168   32.168 win32.py:46(run)
      180    0.007    0.000    1.771    0.010 win32.py:83(_timer_func)


   237600    0.416    0.000   17.069    0.000 window.py:60(SetTile)
   237600    0.646    0.000    2.174    0.000 window.py:72(GetTileTexture)

总时间小于 0.5 秒的所有内容都已被删除，几乎。大部分内容都不会成为问题。

这是我敲了半分钟键盘的结果。在大多数情况下，我每秒可以更改 2 或 3 次屏幕。我个人希望能尽快敲击键盘。哎呀，我的目标是 50-60fps。

win32 运行 10 秒没有花在子函数上是我担心的事情。它可能是空闲时间(即使有一个 pyglet 空闲)，但这不会花在绘图上吗？

我以为慢的部分其实很快；窗口SetTile部分。为了处理图 block ，我有一个 2D Sprite 列表，它们在屏幕上表示它们并简单地更改图像。我认为这不是问题。

我看到的另一个潜在问题是我的更新 - 每次调用时我都必须迭代大约 2400 个图 block 。然而，情况似乎并没有那么糟糕。 90 次按键仅需 0.7 秒。

我开始怀疑这是否表明 Python 速度太慢，无法满足我的需求。话又说回来，不应该这样。我正在做的计算量并不是很大。

tl;dr Python 中的 win32 事件循环是我的瓶颈吗？这意味着什么？如果不是，我可能在哪里失去了速度？

如果需要，可以使用代码。我假设它是 pyglet 使用的 Pywin32。

Answer 1

修改后的答案:我删除了那些毫无值(value)的信息列，例如 self 时间、调用计数和每次调用时间。然后我按照时间降序排列它们，并丢弃小的。

cumtime  filename:lineno(function)
 32.168  <string>:1(<module>)
 32.168  win32.py:46(run)
 20.531  engine.py:58(Update)
 17.069  window.py:60(SetTile)
 11.995  sprite.py:349(_set_texture)
  9.062  sprite.py:365(_create_vertex_list)

Cumtime 是指特定例程在调用堆栈上的总时间。因此，很自然地，一些高级例程会在堆栈上停留 32 秒。其他人在堆栈上的时间较少。例如，_set_texture 大约有 1/3 的时间处于事件状态，而 _create_vertex_list 也大约有 1/3 的时间处于事件状态。这表明顶点被创建了很多，而不是被重复使用，所以也许您可以通过不重新创建它们来节省大约 30% 的时间。

但这只是猜测。无需猜测。

你需要知道的是时间语句的分数(不仅仅是函数)您的代码在堆栈上处于事件状态。您需要知道这一点，因为如果存在性能问题，就是这么一行代码。

Here's how the problem can be found if you have one.

探查器似乎基于gprof，并且here are some comments about that .