This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/15781] improve pass-2 function suggestions


https://sourceware.org/bugzilla/show_bug.cgi?id=15781

--- Comment #1 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Jonathan Lebon from comment #0)
> 1. Also suggest things for optional probes
> 
> This is also mentioned in the code in tapsets.cxx:7189. In a nutshell, if a
> probe contains optional probe points, then suggestions should also be
> offered for the optional ones if none of the probe points could be resolved.

Clarification on what this means:

probe kernel.function("not_a_func") { next }
   -- p2 fail, suggests alternatives to function name

probe kernel.function("not_a_func1"), kernel.function("not_a_func2") { next }
   -- p2 fail, suggests alternatives for both function names

probe kernel.function("not_a_func1")?, kernel.function("vfs_read") { next }
   -- works, does not suggest anything

probe kernel.function("not_a_func1")?, kernel.function("not_a_func2")? { next }
   -- works, does not suggest anything (assuming there are other probes in the
script, otherwise p2 fail with 'no probes found' and no suggestions)

probe kernel.function("not_a_func1")?, kernel.function("not_a_func2") { next }
   -- p2 fail, suggests alternatives for the non-optional probe point only

What we're describing in this PR is that in the last case, we should suggest
something for both probe points, regardless of optionality, because the whole
probe failed to resolved. We could also extend this to catch the before-last
case as well if it would result in a p2 fail.

This might be more trouble than it's worth, especially due to globby probes and
recursive calls, as well as performance issues, if the approach relies on
calculating suggestions for each probe point prematurely.

> 2. Improve levenshtein() algorithm
> 
> - Since we're only going to be printing MAXFUNCS functions, we can abort the
> calculations in levenshtein() at any point we know that the final score will
> be higher than the top MAXFUNCS functions already calculated. This is also
> mentioned in the code in util.cxx:1087.
> - An easy way to quickly improve performance is to compare the length of the
> strings right from the start. If their diff is larger than the max, then
> abort.

This was done in commit 59b11ea.

-- 
You are receiving this mail because:
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]