Opened 8 years ago

Closed 8 years ago

#1669 closed bug (fixed (in master))

Lots of extraneous Term_refresh calls impacting performance on OS X Lion (10.7)

Reported by: mtadd Owned by: myshkin
Milestone: 3.4.1 Keywords: Mac OSX performance
Cc: matt.tadd@…


The new Cocoa window implementation's performance has slown down dramatically on my Macbook running OS X Lion when lots of Term_refresh calls are done in succession. I noticed this at first when running down corridors or resting for a long count. Typically, it take about 5 seconds to process all the refreshes generated during a 99 rest countdown. If I comment out the call to [angbandContext displayIfNeeded] in main-cocoa.m Term_xtra_cocoa() TERM_XTRA_FRESH case handler, the problem disappears. Instrumenting that method, it look like it takes about 20 ms to process the game loop while resting with only the 1 game window enabled...or about 2 seconds to process 99 rest turns. If I add the monster and object list subwindows, they also get a Term_refresh() during each rest turn, and interestingly, if I check [[[angbandContext] activeView] needsDisplay], it returns NO for those windows, yet those 2 extra windows add an additional 2 seconds to the 99 rest turn sequence.

My solution has been to not call [angbandContext displayIfNeeded] during the TERM_XTRA_REFRESH handler, and I haven't noticed any impact to the game thus far. Something else must be ensuring display invalidation, as it seems this codepath isn't necessary, at least in the Cocoa implementation.

Additionally, I get a big slowdown due to excessive calls to Term_refresh during character creation with the default subwindow layout. When selecting the race, class, or roller type, I get 65 calls to Term_refresh() to Term 7, which is the compact player overview. I notice its re-rolling the stats each refresh, which take on average about 15 ms on my machine. So, that's 15*65*3 = 3 seconds of unresponsiive UI during character creation for a subwindow refreshing that is typically hidden behind the game window at this point. My solution above also gets rid of this delay.

Attached is a patch to main-cocoa.m that adds some instrumentation to view how often screen refreshes occur. I have the output going to stdout, which can be displayed by running the angband executable inside the generated App package from the command line.

Attachments (1)

0001-instrumentation-for-TERM_XTRA_FRESH.patch (2.5 KB) - added by mtadd 8 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 8 years ago by mtadd

  • Cc matt.tadd@… added
  • Keywords Mac OSX performance added

comment:2 Changed 8 years ago by myshkin

  • Owner set to myshkin
  • Status changed from new to assigned

comment:3 Changed 8 years ago by myshkin

  • Milestone changed from 3.4.0 to 3.4.1

comment:4 Changed 8 years ago by myshkin

  • Resolution set to fixed (in master)
  • Status changed from assigned to closed

Closed in commit 8ebbfb5 of master, with some help from 3657a68. Thanks for the report and the fix. I am still not entirely sure which code paths are generating refreshes, but there were clearly too many.

Note: See TracTickets for help on using tickets.