gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Profiling Traces


From: Ivan Vučica
Subject: Profiling Traces
Date: Mon, 23 Dec 2013 15:49:52 +0000

Thread necromancy!

During GSoC2013, I would have loved to have something like the contents of "Drawing.log", annotated with screenshots and perhaps some additional state etc. As you mentioned, it would have helped a lot in development of the Opal backend.

Is something like generating screenshots (or making a function call), then integrating an <img src="" inside the log, possible with TESLA?

Any instructions on using TESLA?

On Wed Oct 02 2013 at 3:59:25 PM, David Chisnall <address@hidden> wrote:
Hello all of the GNUstep developers,

We've recently been working on a tool called TESLA that allows you to write temporal assertions (e.g. before you get here, this other function must have been called and returned this value) that are checked at run time, but also provides a convenient way of adding instrumentation to programs.

I've uploaded a couple of profiling traces to give people an idea of the kinds of thing this can generate:

http://theravensnest.org/Drawing.log
http://theravensnest.org/NSCursor.log

The first is a log of all of the drawing messages in the protocol defined by NSGraphicsContext (i.e. the thing used to communicate between -gui and -back), indented based on the current view and cell that is responsible for the drawing.  This doesn't provide a full stack trace, just some context.  The motivation for this is Ivan's work on the Opal back end, and looking at exactly how the back end is used.  Are we doing too many pushes and pops of graphics state, or saving and restoring when we don't need to?  Are we calling methods a lot that are poorly optimised in the back end?

The second is a stack trace, generated in every place where we call a push or pop method.  The motivation for this was the recent work trying to find bugs in the NSCursor balancing code.  Unfortunately, I wasn't able to reproduce the bugs when I tried (maybe they're all fixed?) and so this isn't very useful, although it might be interesting.

Can anyone else think of other useful traces that we might want to generate?

David

-- Sent from my Apple II


_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]