-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibility to see function call arguments in flame graph #46
Comments
Unfortunately no, there is no way to see arguments passed to the function calls. Arguments can be large, so including them with each call could result in massive amounts of data being written to disk. And viewing it as an SVG could be impossible if the size of the data exceeded your machine's available memory. I suppose we could have some sort of argument processor callback that would get passed the raw arguments for each function call, and then that function would be responsible for returning a string representing a truncated/simplified version of them. That's not a feature that exists currently but I suppose it could work. Thoughts? |
That would be an opt-in option, so the user could enable it only when they know what the hell there will be not much of a problems with arguments. Alternatively you could mark which arguments you would like to persist instead of persisting them all (like in my case I would like to track only single argument instead of all of them). |
Yes, I'm thinking something really simple here. Arguments are a list, but each call name in the flamegraph is a string. I'm thinking the optional callback would be something like this: -spec callback_fun(module :: atom(), func :: atom(), args :: list(any())) :: iolist() It'd take a list of arguments and return a binary or iolist representing the simplified representation of them. The returned string would be formatted in the flamegraph like this:
I'm thinking |
That would be 100% enough for me. |
I am working on performance optimisations of Supavisor project. There we extensively use
gen_statem
module so without seeing what are the arguments of called functions it is hard to analyse the stack trace. Is there any option to track arguments of called functions to be able to pinpoint which particular case was the problematic one?The text was updated successfully, but these errors were encountered: