Receiving debugdevice stdout or stderr messages through socket connection?

Page 2/2
1 |

By Sandy Brand

Master (245)

Sandy Brand's picture

08-04-2015, 00:54

Sorry for the late reply!

Again many thanks for all the help! I have managed to put some rough tools together using C++ and C# in order profile my project.

In the end I went for the simplest approach whereby I send a message every time a scope is entered or left.
This makes it slightly easier to have the synchronization done in the profiler itself (you just enable it, and it will discard any scope transitions until it hits the 'root' one). And potentially, it will even allow me to do profiling while I am running the debugger as well (that could be really useful I think).

Here are some screenshots for anyone that is interested:

Screenshot: Raw time-line
Screenshot: Time-line per 'thread'
Screenshot: All scopes per 'thread', sorted by inclusive duration

This already provides me with a workable solution for my project; a real profiler would need many more advanced features though. But at least I now know where to start optimizing.

Only one little problem remains though: as soon as I start sending the messages using Tcl, the application slows down to a crawl.
I suspect it starts to choke on the many messages that are echoed at the top of the screen. Is there a way to send messages over the socket in a 'silent' way?

By Grauw

Ascended (10074)

Grauw's picture

08-04-2015, 01:35

Looks really impressive! (and useful)

By Manuel

Ascended (18162)

Manuel's picture

08-04-2015, 20:55

How exactly are you sending the messages?

By ARTRAG

Enlighted (6550)

ARTRAG's picture

08-04-2015, 22:48

Where can I download the profiler, it could be very useful.

By Sandy Brand

Master (245)

Sandy Brand's picture

08-04-2015, 23:07

Manuel wrote:

How exactly are you sending the messages?

debug set_watchpoint write_io 0x2E 1 profiler_enter_scope

proc profiler_enter_scope { } {
   set now [machine_info time]
   message "profiler_enter_scope ScopeID=$::wp_last_value Time=$now" info
}

By Manuel

Ascended (18162)

Manuel's picture

08-04-2015, 23:47

ah, with message... that proc is indeed meant to show a message on the OSD... (as the help is saying)

It also means that any other message that is sent will end up in your profiler... but I guess that you check whether it starts with "profiler_enter_scope".

If you don't want the OSD to display something, you could change the message callback setting that arranges this.

Try:
set message_callback
and you'll see it's pointing to osd::display_message.
This message_callback setting contains the name of a proc that will be called when there's a message available. You can override it (e.g. by unsetting it, or setting it to an empty string), but make sure you restore it when you're done profiling Smile if you messed it up, don't worry, this setting will never be saved.

Instead of message, you can probably also send something to stderr with puts stderr "bla" but it will end up raw in on the other side.

Previously we never needed this... we usually let the other side perform a command and let openMSX send a reply. I guess we never had a situation before where we want to send something from openMSX to a client.

So what we typically did was not running a script on openMSX side, but just send the script commands from the client to openMSX and check what it replies. Take a look at the debugger code (or the unreleased PyQt Catapult) to get more examples of that.

By Sandy Brand

Master (245)

Sandy Brand's picture

13-04-2015, 00:16

Thanks for the help Manuel!

When I start profiling I execute:

set profiler_old_message_callback $message_callback
unset message_callback

And when I stop profiling:

set message_callback $profiler_old_message_callback

That works like a charm and there is no longer any slowdown!

By Sandy Brand

Master (245)

Sandy Brand's picture

13-04-2015, 00:19

ARTRAG wrote:

Where can I download the profiler, it could be very useful.

It still needs quite a bit for work and cleaning-up before it is fully usable.

However, when I find the time I will improve it and hopefully share it with you guys at some point.

(do note though that it is a solution that is more or less 'tailor made' for my code-base, so it might not be useful for everyone).

Page 2/2
1 |