Approaches for profiling Prolog code in Scryer?

[dcnorris]

The simulation experiment reported in the paper mentioned in #2995 runs so slowly that I would even consider porting some of it into new Rust builtins if necessary. But first, I would like to gain some global impression of where the time is being spent. (I'd like if possible to do 10,000 replications for v2 of the paper, instead of the paltry 1,000 of v1!)

What are you all doing these days, when you need to profile a Prolog program?

[hurufu]

You can use time/1 to count inferences. If you want to exclude a particular predicate (for example foo/1) from counting you can mark it with

:- non_counted_backtracking(foo/1).

It isn't extensively documented, but commonly used in sources. #2534

[dcnorris]

This would be a way to check certain 'suspect' predicates for their contributions to the inference count, then. And I suppose a divide-and-conquer approach could be implemented using macros (cf. #3036)!

[hurufu]

When I really have to understand why performance is bad, I just step through the code (in SWI usually) and observe the execution pattern, and from that I do my conclusions on how to optimize it. I'm not aware of any better and practical way, and I would glad to hear it from others too.

[jjtolton]

You could also do something very fancy like do a goal expansion and thread every goal with a difference list (like they do with DCGs) if you find "mutating" with bb_put and bb_get distasteful, but it would probably be a lot of extra work.

[hurufu]

Consider predicate foo/1, let's say that first solution it can give in 1s, then next 5 solutions in 1ms and then 6th solution in 10s. And results of it are used in a program being profiled. How to count this? Just sum it all up? I don't think so, and I don't know.

[dcnorris]

In my application, this would occur because I had explicitly requested all solutions, and so these several timings would all properly constitute parts of the total run-time to be accounted for. If foo/1 were called many times, then the mean performance would be the most important 'moment' of its performance distribution. That's not to say of course that the worst-case performance seen in the 10s maximum run-time wouldn't be interesting! But in my case, I'd like 1h runtime to yield 10,000 replications of my simulation instead of current 1,000.

[dcnorris]

but it would probably be a lot of extra work.

I wonder if it might be easier to instrument the WAM itself. This would seem at least a good project for learning Scryer internals.

[dcnorris]

Saving JJ the trouble ...