From mboxrd@z Thu Jan  1 00:00:00 1970
From: mbligh@google.com (Martin Bligh)
Date: Wed, 8 Oct 2008 09:06:43 -0700
Subject: [ltt-dev] LTTng specialized probes
In-Reply-To: <48ECD814.4030705@web.de>
References: <5df78e1d0809231814i4b9b98eeyfb9746e5dbb9eb72@mail.gmail.com>
	<20080924072503.GA15570@bolzano.suse.de>
	<532480950809240032t644448f7lc4fdc0dffca69b9@mail.gmail.com>
	<20081006141113.GE1808@Krystal>
	<5df78e1d0810061055q1f02a1f0uac1cf0981fba8f40@mail.gmail.com>
	<5df78e1d0810071116i2e9790cdx8d5854dbfa50cfaf@mail.gmail.com>
	<6cc912950810071428m459aff32tb5fad99e45648170@mail.gmail.com>
	<20081008000727.GA22427@Krystal> <48ECD814.4030705@web.de>
Message-ID: <33307c790810080906k3314b0b6ib7e565f29c0848dc@mail.gmail.com>

> Has anyone thought of / tried out some caching mechanism for this task?
> I mean, scan the format string once (I don't think it will change during
> runtime... :->), save somewhere that it expects n bytes of
> to-be-serialized data on the caller's stack and then get away with only
> copying those over into the trace buffer on succeeding marker hits?

Is it crazy to think of this as "everyone registers a print function", and
we just provide a default print function that takes a string that people
can use if they are not concerned with efficiency? Possibly with a different
macro header if need be to hide it.

Another random thought ... was talking with Michael and Jiaying here about
the markers, and it seemed one of the performance / complexity issues
was the necessity to call multiple tracers from one marker (disclaimer:
I haven't had the time to look at this in any detail, sorry, so please forgive
if this totally misses something ...). Would it be possible to always just have
one thing attached to the marker - this would be optimal for the common case.
In the event that we do need multiple tracers attached, we could simply make
the one thing attached to the marker a multiplexor that called a list of tracers
(transparently).

I expect this would reduce complexity and speed up the common case, at the
expense of a little performance in the uncommon case. Though all of this
is fairly second-hand, so maybe is not useful ;-( Sorry, buried in
Google-specific
stuff right now.