Profiling MCServer
#1
Here are some profiles of MCServer. Please add any if you have some, along with a description.

My two are made by callgrind, on x86_64 Linux Ubuntu.

Loading and Sitting
Generating a new World
Reply
Thanks given by:
#2
It's not meant to be human-readable, is it?
Reply
Thanks given by:
#3
No, you need kcachegrind

Looks like Compression is one of the biggest single things in these profiles. It might be worth tuning the compression value a little.
Reply
Thanks given by:
#4
Okay, thanks.

How does the redstone simulator perform, could I ask?
Reply
Thanks given by:
#5
I have no idea how to interpret those.

Tigerw, if you want easy-to-get, easy-to-interpret results on Windows, try compiling the solution in ReleaseProfile mode and then using the $/MCServer/run_profile.cmd script. Have a look inside the script, first, it will point you to the tools you need to install. You may need to run the script elevated (as admin) on WinVista+.

It produces results like these:
[Image: profiler_gen.png]
Reply
Thanks given by: tigerw
#6
@tiger. The readstone simulator isn't coming up on the traces much so its very fast when not being used.
Reply
Thanks given by: tigerw
#7
Thanks xoft and tycho.

I'll have a look at profiling on windows soon.
Reply
Thanks given by:
#8
Currently the biggest CPU eater for me is the mob processing - it allocates and deallocates several structures for all mobs every tick; the allocations are killing everything.
Reply
Thanks given by:
#9
For me mobs are using about a third of cpu but there spread over a lot of functions so its hard to find somewhere worth optimising. For me the big cpu killer is compression, consistently using a third of cpu regardless of load. It might be worth tuning the compression parameters or looking at why so many chunks are being saved.
Reply
Thanks given by:
#10
(01-17-2014, 02:34 AM)worktycho Wrote: For me mobs are using about a third of cpu but there spread over a lot of functions so its hard to find somewhere worth optimising. For me the big cpu killer is compression, consistently using a third of cpu regardless of load. It might be worth tuning the compression parameters or looking at why so many chunks are being saved.

I think the mob code was slow because it had to gather all the mobs each tick or something, but that might already have changed.
Reply
Thanks given by:




Users browsing this thread: 6 Guest(s)