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部分。为了处理图块，我有一个 2D 精灵列表，它们在屏幕上表示它们并简单地更改图像。 我认为这不是问题。

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

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

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

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

Answer 1

修改后的答案：
我删除了那些毫无价值的信息列，例如自我时间、呼叫计数和每次呼叫时间。
然后我按照时间降序排列它们，并丢弃小的。

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% 的时间。

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

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

如果您遇到问题，请按以下步骤查找问题。

探查器似乎基于gprof，并且这里有一些关于的评论。