Linux Profiling

ID:1955447
 
Oct 4 2015, 9:29 pm
Applies to:
Status: Open
Issue hasn't been assigned a status value.
Windows' version of DreamDaemon is capable of profiling running games, but Linux's CLI version is not. A simple change to balance this out is to implement new execution arguments for outputting CPU/Network profiles for a running DreamDaemon process.

For example:

// I'm not sure how DreamDaemon internally differentiates separate instances of itself...
// So in this case there is already a DreamDaemon "game.dmb" instance running.
// Alternatively you could just input the process' PID or something? Unsure.

DreamDaemon --CPU "game.dmb" | less
DreamDaemon -C "game.dmb" > ~/cpuprofile.txt

DreamDaemon --NET "game.dmb" | less
DreamDaemon -N "game.dmb" > ~/netprofile.txt


This would help tremendously!
Oct 5 2015, 6:43 am
Can't you profile if you set yourself as an admin via that config file, then use the .profile verb in game?

Oct 5 2015, 8:16 am
Well, ideally, a way to automate profiling (in both linux and windows) so it dumps to a file that is later uploaded to a place all coders can see with having to give all coders the power to restart the server would be super handy.

Oct 5 2015, 9:09 am
In response to MrStonedOne
MrStonedOne wrote:
Well, ideally, a way to automate profiling (in both linux and windows) so it dumps to a file that is later uploaded to a place all coders can see with having to give all coders the power to restart the server would be super handy.

I would like this, as well as a flags param for cfg/admin.txt so that one could separate out reboot/debug permissions a little bit. I've not made a feature request for it, though, because I imagine it would require quite a bit of work from where it sits now.
Oct 5 2015, 9:12 am
for the meantime, i suppose you could kinda do this by overriding world.reboot(reason), and if the reason is 1, checking usr. as using the reboot verb sets usr (as of 508).

Oct 5 2015, 10:42 am
I don't think piping output to a file would be possible for profiling purposes, because piping is basically a one-shot deal. Profiling has always been interactive by nature, requiring start/refresh/stop/clear commands to function.

One thing I think might be nice for Linux DD is some kind of console mode where you can type in various commands. The only thing is, I don't know of any way offhand that I could open up a console on a running background process.
Oct 5 2015, 10:43 am
How about a in code interface?
Oct 5 2015, 11:36 am
Profiling is accessible in code via client/Topic(), provided the user has proper admin/debug clearance in the server config. Profiling used to always be done through the browser control, and that method should still exist (though not for network profiling, which was never given a browser interface). I figure that's the method that makes the most sense to use with the webclient.
Oct 5 2015, 11:42 am
Well the idea I had, for /tg/station13, would be a way to do per-day profiles, and automate uploading them to the public log interface as a csv or an excel file with some other calculated data like 10 digit precision self cpu per call, total cpu per call, real time per call. (basically, both total, and avg in one sheet, but with more than 3 digits of precision for avg)

So an interface to start, stop, clear, and fetch profile data programmatically would be ideal, and kinda sorta help out linux as well.

Can this be done with client/topic?
Oct 5 2015, 11:44 am
The setup is browser-based and might only work in the default browser. I'll have to explore that. Ideally I'd want this to appear in a popup, at least where the webclient is concerned.