From: David W. <wa...@cs...> - 2004-01-14 19:55:46
|
Bart Demoen writes: > Here is another thought: write a routine which has as input a > codepointer and as output the name/arity/module of the predicate which > has that codepointer (even in the middle of a clause, but certainly as > an alternative clause pointer). It can come in handy for other things > as well. And it avoids the need for a special compiled version of XSB > for doing the profiling - and without overhead during execution. Ahh yes. Good idea. The problem in XSB is that it doesn't automatically maintain information that makes that code_addr->name/arity/module mapping easy. It only builds that info if profiling is requested. And that is why I now require a command-line option to enable profiling: so that the overhead of maintaining that table is only done if profiling is desired. But this is still a good idea for us, since it makes it easy to do this choicepoint testing with profiling. The reason the code_addr->pred_name table isn't easy in XSB is because of its memory management, of course. I'm thinking about how to improve memory management to make this table much cheaper to maintain, and if I can do that, then profiling can aloways be available. Thanks for the idea. -David P.S. > Just to show you something of how it is done in hProlog (*) > (*) I apologize for mentioning it so often; if it gets annoying, just yell No apology necessary. Look how often I mention XSB. And besides, I keep learning interesting new stuff from you, that comes from your work on hProlog. But why in the world does hProlog implement such a weirdly named predicate to get the choice point address (or displacement?) :-). |