vmprof-python
vmprof-python copied to clipboard
vmprof
Total time passed is missing
Hello,
I believe the total time elapsed is missing from the cli and web outputs at least, and I believe also from the file. When making comparisons, a relative time shift is important though. And esp. for differences between runs it's essential.
Can you add this information?
Yours, Kay
Wall clock time of the overall recording in best resolution is probably OK.
I found "time.clock_gettime" and we could use it with CLOCK_PROCESS_CPUTIME_ID, but there is nothing for Python2 like that. Any ideas there?
it's a C extension anyway, so that's hardly a problem. Wall time is fine too I guess
I am using clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1); and then something to calculate the differences. I am going to make a pull request later with that kind of thing I suppose, while I try and workaround things for now.
You are not using CFFI for the bindings to "_vmprof", are you?
Yours, Kay
In the current master, the datetime including the timezone is saved before and after profiling. It does not have better resolution than seconds.
Is that enough or do you need better resolution? Usually profiling a program that runs under a second might not be worth knowing how long it takes?
Um, it's written in microseconds. Not sure about the Python side of things, but at least the profile has microsecond resolution
right, I forgot about that because the datetime extracted did not show microseconds, but we really save it!
Just for the record. I am trying to match CPython runs of a program against Nuitka runs of a program, in order to find parts of the program where CPython is faster easily.
So, when a user tells me, my program is not accelerated or even de-accelerated, the idea is to not tell which part of his program is the slowest, but which part is the least accelerated, and turn that into a report information. I would then e.g. look at that part and notice with other kinds of tests what this is.
Also, I want to score parts of the program by making divisions, and use the absolute run time of the program in that. So if a function was visible on the stack for 20% of 0.5s total run time vs. 80% of 0.1s total run time, i.e. 0.1 vs 0.08s, that should still mean it was accelerated, just not by a lot, only 20%.
Due to lack of warm up, this can be more precise for Nuitka than for PyPy which is skewed by the JIT warm up. A program that ran a second beyond "site" module, which I am not going to trace, will already be good enough to make statements in my case.
Seems like it's a good time to revisit the topic. I just need to find the time. But in principle this is a must have to me for next EuroPython to show off. Without users being able to tell if, and if not why, their programs are or aren't faster, development will be about hunting down specific programs manually, which is quite wasteful, or least laborious and not fun.
Yours, Kay