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。

令我感到不安的是，在子功能上花費了10秒的win32運行時間。 它可能是空閑時間（即使有一個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和這里有關於一些評論 。