Performance patches

[stefan2]

Hi there,

Just for fun, I've been profiling and patching Wesnoth (1.18 code base). The overall effect is >2x speedup with plenty of future potential. There was no single you-done-goofed hotspot, so I ended up with ~100 small to large-scale changes. Areas touched include

• map drawing logic

• config data structure

• Lua interface (lua_unit & friends)

• Lua memory management

• data/tools/wesnoth/wmltools3.py (about 10x speedup, mostly by improving regex handling)

My question to the devs: Are you interested in such changes or do you feel that you are already in a good place performance-wise? If so, for which parts would you want me to start submitting PRs?

-- Stefan^2.

[gnombat]

Just for fun, I've been profiling and patching Wesnoth (1.18 code base).

Note that it would probably be better to work with 1.19 here (or even better, the latest Git commit) because that is where all development is happening - the 1.18 branch basically only gets bug fixes, so I'm not sure if performance-related changes would be accepted (unless it's fixing a really bad problem).

My question to the devs: Are you interested in such changes or do you feel that you are already in a good place performance-wise? If so, for which parts would you want me to start submitting PRs?

I'll let actual developers answer that one. (As a Wesnoth user, I would certainly welcome better performance.)

[stefan2]

Just for fun, I've been profiling and patching Wesnoth (1.18 code base).

Note that it would probably be better to work with 1.19 here (or even better, the latest Git commit) because that is where all development is happening - the 1.18 branch basically only gets bug fixes, so I'm not sure if performance-related changes would be accepted (unless it's fixing a really bad problem).

Sure, I'm aware. My prototype changes need to be turned into "proper" code and the PRs would be against HEAD.

[Soliton]

Without seeing more details who knows. I suggest starting with something simple and just open a PR.