PERF: Behavior caching

[Wincent01]

Make sure you've done the following:

• [X] I have checked that this issue has not already been reported.

• [X] I have pulled the latest version of the main branch of DarkflameServer and have confirmed that the issue exists there.

DarkflameServer Version

485de61

Environment

Manjaro Linux 32 GB RAM Intel Core i5-9600K x 6

Reproducible Example

#621 drastically increased memory usage. This comes as a result of caching the entire Behavior Parameters and Behavior Template tables. The Behavior Parameters table in particular is the largest one by far in the database, and the reason I chose to not cache it all at startup. Behavior Template is also one of the largest, and also contribute significantly to memory usage.

My testing, see below for numbers, shows a 28MB increase is memory usage, which can add up when that applies to all world, including properties, which double in memory usage.

The reason this addition was to avoid the lag with the initial use of a skill, but I don't think this tradeoff is worth it. One compromise would be to look at all of the items a player has at login, and preload that set of behaviors, instead of caching every behavior at server startup. Speculation: 95% of skills will never be in use in a particular session, and could be kept out of working memory. Or leave it up to a compiler tag.

Prior Performance

Pre #621 AG: 42MB NS: 34MB BY: 27MB

Post #621 AG: 70MB NS: 62MB BY: 55MB

[Wincent01]

I'd recommend the use of valgrind when developing on Linux.

Here's a command I used to profile the memory usage and leaks:

valgrind --leak-check=full --show-leak-kinds=all --log-file="valgrind_log_WorldServer.out" -v ./WorldServer -zone 1200 -port 2010 -instance 1 -maxclients 15 -clone 0

[EmosewaMC]

The player experience was greatly hindered in most instances and would also cause lots of "unknown" lag spikes as reported quite a few times. Considering how many strings there are ill look into caching those as well so we don't store a new one every time.

[EmosewaMC]

With caching just the parameters table strings I am able to get this increase down to only 18MB increase overall. Looking at other ways to bring this down.