Functions with zero 'call counts'

[voidmonoid]

Hi Artem:

First off: fantastic effort , very useful and very performant front end. I used it to quickly isolate some bottlenecks and the performance while instrumented was also super. Very glad to have found your profiler.

I have been through the closed issues and faqs and managed to get a lot of my issues resolved. The one major one remaining is inconsistency in how some outer functions are reported with 0s in all the columns. Looks like issue #15 reports my problem almost identically: except that I do not have any message-loop spinning inside the call.

My configuration is more like

C# doSomethingViaPInvoke()
..
extern "C" bool pInvokeMethod()
{
  logging
  someInnerMethod1();
  return someInnerMethod2();
}

and most of the runs, "pInvokeMethod" is listed with all 0's which makes it hard to compare the results across different runs.

You did respond to #15 by stating that

The call to the function 'outer' (see below) will have zero 'Calls Count' provided that 'inner' is a
call long enough to span several profiler output updates.

void outer() { inner(); }

Is it feasible to remove this limitation ? Or if there is a performance/memory tradeoff, maybe an option or an environment variable that allows it to be tuned ?

[tyoma]

Hi! Thanks for trying it out! Do the figures turn non-zero once the program exits? It's an error if they don't.
I'll make this a suggestion - it seems there's a potential, but the thing I'm worried about - is that it may compromise measuring precision.

[voidmonoid]

Hi Artem, Thanks for responding quickly. And yes, you are right, when the app is closed, the 0 values correct themselves and everything makes sense again. That is good enough. Maybe put an asterisk or something on the 0 values with a static text in the frame stating that 0 will fix itself when the app closes ? Or maybe even a FAQ entry. So far loving it. So incredibly easy to use and so useful. Great job on the tool. thanks,

…

-vamsi

On Mon, Oct 1, 2018 at 8:35 PM Artem G. ***@***.***> wrote: Hi! Thanks for trying it out! Do the figures turn non-zero once the program exits? It's an error if they don't. I'll make this a suggestion - it seems there's a potential, but the thing I'm worried about - is that it may compromise measuring precision. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ApqYXr7NrqMYjrA1MyWgKfJa7AZNos5Pks5ugt8OgaJpZM4W_vm-> .

-- Between impulse and reaction lies man's greatest strength: The freedom to create a choice, to create his universe, to choose - Victor Frankl (adapted)

[tyoma]

I think marking function as "long-running" is quite a useful thing. Let's make it that way.

Thank you!!
P.S.Meanwhile, if you don't mind - please leave a review on MS marketplace: https://marketplace.visualstudio.com/items?itemName=ArtemGevorkyan.MicroProfilerx64x86

[r-pankevicius]

Is this issue not an issue but "enhancement", @tyoma?

I use micro-profiler_standalone.exe and run playground.exe with slightly modified main.cpp:

void a_heavy_load_function(int iterationCount)
{
	vector<double> v(iterationCount);

	generate_n(v.begin(), v.size(), &my_random);
	sort(v.begin(), v.end());
	sort(v.rbegin(), v.rend());
	sort(v.begin(), v.end());
	sort(v.rbegin(), v.rend());
}

#if !defined(_DEBUG) && !defined(DEBUG)
const int NUM_OF_ITERATIONS = 300000;
#else
const int NUM_OF_ITERATIONS = 30000;
#endif

int main()
{
	srand(static_cast<unsigned int>(time(0)));

	a_heavy_load_function(NUM_OF_ITERATIONS);

	return 0;
}

I get zeros for main and a_heavy_load_function:

Now, let's rewrite main() this way:

int main()
{
	srand(static_cast<unsigned int>(time(0)));

	a_heavy_load_function(NUM_OF_ITERATIONS / 3);
	a_heavy_load_function(NUM_OF_ITERATIONS * 2 / 3);

	return 0;
}

Now main have zeroes and 1 call (of 2) is recorded for a_heavy_load_function:

1 call is missing in both cases. Or is it some timing issue similar to #59 ?

[tyoma]

@r-pankevicius there're two things to the issue - you're right, one is that the last call gets lost (this is #59), the other - is that a long call in progress gets no representation in frontend. The latter is probably an enhancement. The former is a requirement bc an instrumenting profiler is expected to be 'call-accurate' :)