Linked hash map map memory implementation comes with extreme cpu use

[l29ah]

Describe the bug
9bfc9b3 is the first bad commit
It even makes running snow slow!

To Reproduce
Steps to reproduce the behavior:
Build the game.
Load an existing game.
Enjoy.

[cadyb]

I also noticed a very high cpu 97% usage when running 7a7bec0
It seemed to get worse the more tiles the character could see. Inside a house with the curtains drawn was seemingly fine but as soon as you went outside it would take seconds to move a single tile
Updating to d6c0138 doesn't solve the issue
Reverting back to 30a0822 the commit before bfc9b30febdb57ac98708c11f9da3486832a0a1 drops cpu usage down to 11%

All CPU %s where tested in an open field.

[ZhilkinSerg]

Can you provide lagging savegame?

[kevingranade]

Are you seeing this on tiles or curses?

[kevingranade]

Thanks for reporting that it's happening when snow effects are displaying, that's a valuable clue.
I suspect what's happening here is that you have animation rate set relatively high, and the weather animation code calls map::drawsq() or the tiles equivalent to re-draw an individual map tile to "erase" the weather glyph or tile. That code then calls the memorize code at a very high rate, driving lots of CPU utilization. It didn't cause a problem before my change because there's a "finalize" method that would do the relatively expensive part of applying those tiles to the memory. I was hoping the new code made memorization cheap enough to not bother with that, and I didn't test this scenario with fast weather animation.

If that's correct, I can probably somewhat resurrect the batching/finalization method and eliminate this slowdown.

[l29ah]

I'm on curses, and i didn't touch the animation settings.

[l29ah]

save.zip

[kevingranade]

After a peek at a profile the animation code, it's clear that at least a component of the problem is that it's calling game::draw_ter() to clear the map instead of doing targeted erasures like I thought it was.

This results in a huge number of useless calls to memorize_symbol() and unordered_map::find().

[l29ah]

The provided save file still demonstrates >10s per step outside of the car, but better than it used to be.
x86_64 Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz GenuineIntel GNU/Linux

[ZhilkinSerg]

Hmm... I cannot reproduce this - the game runs just fine. Though I tried on i7 CPU.

Did you download pre-compiled binary or compiled by yourself? Also have you tried tiles version?

[l29ah]

On Thu, Oct 25, 2018 at 01:45:04PM -0700, ZhilkinSerg wrote: Did you download pre-compiled binary or compiled by yourself? Also have you tried tiles version?

I've built it myself; no i haven't tried it.

…

-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments

[ZhilkinSerg]

What was your compilation command line? Did you use RELEASE=1?

[l29ah]

Just make. No, as i'm trying to catch #26291 meanwhile.

[ZhilkinSerg]

Debug builds were always slow. It is currently terribly slow even for debug build and we should do something, but if release builds are okay that is not a priority.

Could you try compiling and running with RELEASE=1 to make sure it is playable on your system?

[l29ah]

On Fri, Oct 26, 2018 at 03:36:36AM -0700, ZhilkinSerg wrote: Debug builds were always slow. It is currently terribly slow even for debug build and we should do something, but if release builds are okay that is not a priority. Could you try compiling and running with `RELEASE=1` to make sure it is playable on your system?

Yeah, with RELEASE=1 it is playable.

…

-- () ascii ribbon campaign - against html mail /\ http://arc.pasp.de/ - against proprietary attachments