[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Profiling Traces
Re: Profiling Traces
Sat, 28 Dec 2013 12:27:17 +0000
TESLA has a web site, which covers getting started:
For the traces, I actually replaced the debugging printf handler to log the raw
events. We're hopefully going to separate TESLA into some cleaner layering, so
the event-generation code is more isolated from the event-handling code and we
can more easily plug other bits of tracing into it.
If you just want traces of message sends, then the latest version of the
runtime has a mechanism for interposing on a particular selector, which is what
On 23 Dec 2013, at 15:49, Ivan Vučica <address@hidden> wrote:
> 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
> 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:
> 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?
> -- Sent from my Apple II
> Gnustep-dev mailing list
-- Sent from my Cray X1
- Profiling Traces, Ivan Vučica, 2013/12/23
- Re: Profiling Traces,
David Chisnall <=