On 23/03/22 3:02 PM, Bram Moolenaar wrote:
Ernie Rael wrote:
Poking around...
In debugger.c::debuggy_find():976 it looks like there's a missing `break;`.
Hmm, it needs to loop if "lnum" can be lower in another entry, but for
profiling that doesn't matter. I suppose we could break when
"gap == &prof_ga". Do you want to make a PR for that?
Will do.
With my corrected code, has profiling() still looks like ~11% of the the
time (it's got those two vim_regexec...()); wonder if has_profiling()
could/should cache the results of debuggy_find().
Caching can be tricky. In this case it can be difficult to clear cached
information when anything changes (new function defined, profiling entry
added/deleted, etc.).
We're caching the result of running regexp on a name (I think); I don't see
how adding a function changes that. I'm thinking of something like
has_profiling(...)
{
result = table->get(fname, null);
if (result == null)
{
result = debuggy_find(...);
table[fname] = result;
}
return result; // handle direct return and optional forceit
}
The table is cleared whenever prof_ga is modified. Should be easy to
detect since prof_ga is static in debugger.c.
I was thinking of two tables, for file and function, and avoid constructing
keys that distinguish the cases.
A potential problem is "forceit", I'm not sure what this is about and
whether or not it can be cached. If it can be cached, the a value in the
table is two bits, has_profile and forceit (assuming foreit is boolean).
I'm also assuming that the main if condition is always true for
has_profile; "bp->dbg_type == DBG_EXPR" is never true.
Any simple examples of using hashtable in "C" that I can reference?
is it worth it?
Some uniform degradation, while undesirable, is not unexpected when
profiling. The problem here is the degradation in results is not uniform
and is large in some cases; it is due to the regex engine and the order of
stuff in a table that's used by the profiler. Can vary while running.
In this case, `map(in, Map1)`, the map builtin invokes a user defined
function; I'm guessing on invocation of that function the profiler looks it
up. The lookup takes a seemingly arbitrary amount of time and counts it
against the `map`. I've seen results 50x slower for the `map`; while lines
that do not involve a user function are not affected.
-ernie
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/9704325e-60b4-ae3b-7735-e75e4861a612%40raelity.com.
