You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vmprof has the fundamental assumption that code object addresses are unique across the runtime of the program. That is incorrect in many cases, e.g. I think the code object of the global scope of a module dies after importing and the same memory address could be reused by another code object later. If that happens, a random name for the address wins, leading to very confusing stack traces.
An extreme way to show the problem is something like this:
This should show 100 functions f0, ..., f99 but for me on CPython I get just two of them, taking about 50% of the time each, since the memory address of the code object gets reused every other iteration.
This is not a hypothetical problem, I am seeing this occur in practice for large programs such as translating PyPy.
The text was updated successfully, but these errors were encountered:
vmprof
has the fundamental assumption that code object addresses are unique across the runtime of the program. That is incorrect in many cases, e.g. I think the code object of the global scope of a module dies after importing and the same memory address could be reused by another code object later. If that happens, a random name for the address wins, leading to very confusing stack traces.An extreme way to show the problem is something like this:
This should show 100 functions
f0, ..., f99
but for me on CPython I get just two of them, taking about 50% of the time each, since the memory address of the code object gets reused every other iteration.This is not a hypothetical problem, I am seeing this occur in practice for large programs such as translating PyPy.
The text was updated successfully, but these errors were encountered: