[m-rev.] Breakpoint added in source-to-source debugger

[Zoltan Somogyi]

On 09-Oct-2007, oan at missioncriticalit.com <oan at missioncriticalit.com> wrote:
> >This is unnecessarily slow. Using a map from module_name to the set of
> >predicate names with breakpoints in that module would be faster, both because
> >maps are balanced trees while sets are lists, and because if you have
> >breakpoints on more than one predicate in a module other than the current one,
> >a single comparison can ignore them all.
> 
> I totally agree with you, but as you have to enter the breakpoints by
> hand, the set will never contain a million elements because when you are
> debugging an application, you are generally interested by the behavior
> of one or two (or some at the maximum) predicates/functions. In this
> point of view, I don't thing that even a milli-second could be gained
> here.
> 
> I will think on the case where there is a million breakpoints.

You are missing the point.

The case to worry about is when you have something like five breakpoints,
three of them being from the same module, say module m1, the others being
from modules m2 and m3. The typical case is an event that does not match
any breakpoint. The question is: how many tests do you need to execute
before you know that the current event does not match a breakpoint?

With your system: up to five comparisons of pred_id, each of which fail
on the first component, the module name. Since the list is sorted and
you stop the search when you see the first module *past* the one you are
looking for, you will need an average of about three comparisons.
Each comparison is preceded by the extraction of the module name from
the pred_id or proc_id structure.

With my system: the search for the module name of the current event
in a balanced tree with three module names as keys requires two comparisons.
There is only a single extraction of a module name from a proc_id or pred_id
structure, for the current event.

Given that you *will* execute millions of events between breakpoints in many
debugging sessions, this difference adds up.

> >> +:- type breakpoint
> >> +    --->    breakpoint(
> >> +                bp_module_name  :: string,
> >> +                bp_pred_name    :: string
> >> +    ).
> >
> >Both here and in the compiler: did you make a conscious choice to work
> >with predicates instead of procedures? If yes, why? 
> 
> No

It seems that you are inching towards reinventing the string_proc_label type
in the mdbcomp module.

> >And why do you variable names such as ProcId?
> 
> ProcId was choose in common here. As an instantiation of the ssdb_proc_id
> type, it looks like logic to call it like that.
> 
> But I can easily change the name if you wish.

My point is that the name should match the meaning. If it identifies only a
predicate, don't call it ProcId. Same for the type name; don't call it
ssdb_proc_id if it identifies predicates, not procedures.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------