Problem: Execution stack is incomplete and inefficient.
Solution: Introduce a proper execution stack and use it instead of
sourcing_name/sourcing_lnum. Create a string only when used.
1a47ae32cd
Omit test_debugger.vim: superseded by later patches.
Omit check_map_keycodes(): N/A.
Omit kword_test.c: N/A (converted to a unit test).
Problem: Profiling functionality is spread out.
Solution: Put profiling functionality in profiling.c. (Yegappan Lakshmanan,
closesvim/vim#4666)
fa55cfc69d
Move proftime_T to types.h for now to avoid recursive #include.
For "backwards" duration, reltimefloat() should return negative value
like its counterpart reltimestr().
ref bab24a88ab
ref 06af88cd72
ref #10521fix#10452
- reltimestr(): Produce negative value by comparing the unsigned
proftime_T value to INT64_MAX.
https://github.com/neovim/neovim/issues/10452#issuecomment-511155132
1. The interfaces of nearly all platforms return uint64_t. INT64_MAX is
only half of that.
2. Low-level interfaces like this typically define that there is no
fixed starting point. The only guarantees are that it's (a)
monotonically increasing at a rate that (b) matches real time.
ref 06af88cd72fix#10452
Performance of high-resolution time (clock_gettime via uv_hrtime) is
expensive on some systems. For profiling VimL, syntax, etc., we don't
care about nanosecond-precision and monotonicity edge-cases, so avoid
uv_hrtime().
closes#10328
From the uv__hrtime() source:
0cdb4a5b4b/src/unix/linux-core.c (L442-L462)
/* Prefer CLOCK_MONOTONIC_COARSE if available but only when it has
* millisecond granularity or better. CLOCK_MONOTONIC_COARSE is
* serviced entirely from the vDSO, whereas CLOCK_MONOTONIC may
* decide to make a costly system call.
*/
This micro-benchmark (Debug build) shows negligible differences on my
system:
#include <sys/time.h>
...
proftime_T tm = profile_start();
int trials = 999999;
int64_t t = 0;
struct timeval tv;
for (int i = 0; i < trials; i++) {
t += gettimeofday(&tv,NULL);
}
tm = profile_end(tm);
ILOG("%d trials of gettimeofday: %s", trials, profile_msg(tm));
tm = profile_start();
for (int i = 0; i < trials; i++) {
t += os_hrtime();
}
tm = profile_end(tm);
ILOG("%d trials of os_hrtime: %s", trials, profile_msg(tm));
tm = profile_start();
for (int i = 0; i < trials; i++) {
t += os_utime();
}
tm = profile_end(tm);
ILOG("%d trials of os_utime: %s", trials, profile_msg(tm));
ILOG("%zu", t);
Reuse the profiling functions to implement the startuptime functions.
Decreases our dependency on `gettimeofday()` and thus gets us a little bit
closer to a clean port to Windows.
Should be better than gettimeofday() since libuv uses higher resolution
clocks on most UNIX platforms. Libuv also tries to use monotonic clocks,
kernel bugs notwithstanding, which is another win over gettimeofday().
Necessary for Windows, which doesn't have gettimeofday(). In vanilla vim,
Windows uses QueryPerformanceCounter, which is the correct primitive for
this sort of things, but that was removed when slimming up the codebase.
Libuv uses QueryPerformanceCounter to implement uv_hrtime() on Windows so
the behaviour of vim profiling on Windows should now be the same.
The behaviour on Linux should be different (better) though, libuv uses more
accurate primitives than gettimeofday().
Other misc. changes:
- Added function attributes where relevant (const, pure, ...)
- Convert functions to receive scalars: Now that proftime_T is always a
(uint64_t) scalar (and not a struct), it's clearer to convert the
functions to receive it as such instead of a pointer to a scalar.
- Extract profiling funcs to profile.c: make everything clearer and reduces
the size of the "catch-all" ex_cmds2.c
- Add profile.{c,h} to clint and -Wconv:
- Don't use sprintf, use snprintf
- Don't use long, use int16_t/int32_t/...
