Re: Container keys

[John Levon <levon at movementarian dot org>]

On Sat, Apr 30, 2005 at 12:21:15PM -0700, Martin Hunt wrote:

> saw anything using more than two keys.  Do you have some examples of
> where this is useful?

I've two answers to this: first, if systemtap is to be a general
scripting environment, restrictions like this are going to cause
problems: people just *are* going to find situations where they want it.

Second, yes, I do have examples. Unfortunately I can't release the
actual ones I've used. Consider though, that it makes real sense to be
able to key based on application name, *plus* thread id, *plus* probe
function. That basic use is already beyond what current systemtap can
do. What about aggregating on (a certain depth of) call stack? How would
I say "I want to see the number of times which threads had call stacks
from this function" etc. ? systemtap is all about getting a directed
amount of useful data[1] and restricting the way I can accumulate the data
doesn't help this aim.

> We could support an arbitrary number of keys, but it would be less
> efficient than supporting two.

With the static maps code you have now. What prevents the script
compiler from outputting the equivalent of map.c, but with the key/value
types hard-coded? Similar to how C++ templates are emitted. The only
issue I could see with this is module code size bloat for very large
scripts, but I would not expect large scripts to be common. It also
seems to be the only sensible way to support stack traces as keys, which
I would consider a very useful feature.

regards,
john

[1] or at least, that's what I think it /should/ be about