Made a flame graph for malloc operations in a 4 player ffa, me and 3 nexus AI's.
Command used after game launch. Get all malloc operations and stack trace for each along with the sum of bytes requested, then fold into single line and generate flame graph with bytes per operation.
Code: Select all
dtrace -x ustackframes=100 -n 'pid$target::malloc:entry {@[ustack()] = sum(arg0); } tick-60s { exit(0); }' -p 77498 -o warzone.malloc
./stackcollapse.pl warzone.malloc > warzone.malloc.folded
./flamegraph.pl warzone.malloc.folded --title="malloc() bytes" \--countname="bytes" --colors=mem > warzone.malloc.svg
I have found some interesting points on this. (At least to me)
function : warzone2100`updateScripts takes 33.14% of all malloc operations causing all stack traces above such as
function : libQtScript.so.4.8.6`QScriptValue::call 32.96% (likely to change as we go to QT5)
function : displayConsoleMessages takes 24.27% (depends on amount of messages) kind of already known this is a big problem.
function : warzone2100`audio_Update takes 10.02 so not so bad.
By comparison calloc requests are quite different. Same method.
Code: Select all
dtrace -x ustackframes=100 -n 'pid$target::calloc:entry {@[ustack()] = sum(arg0); } tick-60s { exit(0); }' -p 77498 -o warzone.calloc
dtrace: description 'pid$target::calloc:entry ' matched 2 probes
./stackcollapse.pl warzone.calloc > warzone.calloc.folded
./flamegraph.pl warzone.calloc.folded --title="calloc() bytes" \--countname="bytes" --colors=mem > warzone.calloc.svg
Not sure what this one is but
function : libGL.so taking 64.64%
function : warzone2100`audio_Update taking 33.65%
same on memsets as above and apart from main game loop
droidUpdate 32.34%
updatePlayerPower 16.14%
structureUpdate 5.68%