search

featurecat / lizzie

Lizzie - Leela Zero Interface
GNU General Public License v3.0
970 stars 228 forks source link

Lizzie 0.7 - "drawString" causes massive slowdown when large numbers of stones are displayed with visits/winrate text #523

Open AncalagonX opened 5 years ago

AncalagonX commented 5 years ago

I built Lizzie 0.7 maven two weeks ago (using commits current up to March 27th, 2019), and I'm testing it on a Windows 10 Desktop with a GTX 1070 and a decent four-core processor.

Problem: When Lizzie 0.7 displays large numbers of "transparent next move stones" while LZ is pondering, it ends up maxing out CPU usage—often hogging up more processor time than the 24-thread leelaz.exe process it's running! When this happens, Lizzie's refresh rate drops to 1-2 updates per second at best, and the interface response time to mouse/keyboard input becomes even slower than the massively reduced refresh rate.

Cause: Using a Java profiler, I was able to narrow down the source of these slowdowns to the drawString function in BoardRenderer.java at lines 716 and 727 (see this permalink to lines 716 and 727). I couldn't narrow down whether it was only one, or both of these drawString functions—but this is where the culprit is.

The slowdown is determined solely by how many "transparent next move stones" there are displayed with text using drawString.

I tried force-disabling all anti-aliasing I could find throughout the entire Lizzie code (including on the text in question). This did indeed make the text and all graphics ugly and aliased, but made no significant difference in reducing the slowdown. I also inserted constant dummy text instead of having it pull the real visit/winrate data, and still no change in slowdown. It seems to specifically be drawString causing the slowdown.

Holding the [z] button to "temporarily" not show next moves does not make the slowdown go away. However, pressing [SHIFT+Z] to "perma-toggle" not showing next moves does indeed make the slowdown go away completely. Also, disabling the two drawString functions so that visit/winrate text is not displayed on "transparent next move stones" also makes the slowdown entirely go away.

This exact same issue also occurs in earlier builds of Lizzie 0.7, but it is a vastly smaller effect. The increased CPU usage in early Lizzie 0.7 I built on November 15th (shortly after Lizzie 0.6's release, but with a dozen or so new commits) experiences nearly an order of magnitude less slowdown than the recent build of Lizzie 0.7 from two weeks ago.

Here is an example situation just to illustrate what a board with massive slowdown caused by many "transparent next move stones" looks like. This particular screenshot happened to be on move #1 with no stones played yet, using a custom leelaz.exe searching most 19x19 intersections to demonstrate the issue:

lizzie_0_7_next_move_predictions

featurecat commented 5 years ago

Oh I haven't profiled it in a while. I'll try to fix this as best I can, I wouldn't have suspected drawing strings to have been slowing Lizzie down so much. Maybe we can look forward to a speed up.

AncalagonX commented 5 years ago

Just to add a note about the above example: it seems like an extreme case, but this situation occurs regularly in normal games LZ is pondering on within Lizzie. It can be seen most often in games where LZ believes one side is overwhelmingly winning, and tries to search the entire board.

It also occurs regularly when using a modified leelaz.exe designed to search a larger number of moves on every turn. When asked to search a quarter, or half, or all available intersections, it also causes the same massive slowdown due to drawString displaying text on the "transparent next move stones".

I only know just enough about Java to profile it down to the culprit, but I don't know enough to fix it. I couldn't find an easy answer on Google, though it seems there are quite a number of other people complaining about similar problems with drawString performance.

featurecat commented 5 years ago

Well, there's definitely solutions I can think of, such as reducing the amount of text that needs to be drawn. And hopefully we can move off Java to something better in the future. I can address this for 0.7.

zsalch commented 5 years ago

@AncalagonX The Lizzie has made a lot of changes during this period. Don't know if this problem is solved or worse. Or you can turn on the pane UI in the config dialog (Ctrl+X) to see if there are any new changes.