Skip to content

Prototype: Rudimentary stack profiler #529

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

igorwwwwwwwwwwwwwwwwwwww

We have a relatively large jsonnet code base (source), and I was trying to profile slow jsonnet invocations.

The golang-level profile via JSONNET_CPU_PROFILE wasn't very helpful in this regard. And tracing individual calls by adding std.trace was quite combersome.

I prototyped a little sampling stack profiler. It is not very sophisticated. It samples stacks for 1% of calls to EvalInCleanEnv. Those stacks can then be visualised as a flamegraph.

Usage:

JSONNET_STACK_PROFILE=stacks.out jsonnet main.jsonnet
cat stacks.out | flamegraph.pl --hash > flamegraph.svg

There's plenty of room for improvement:

  • Making the code nicer
  • Including a time component (since we currently assume each eval takes a fixed amount of time)
  • Buffering stacks in memory with their counts and writing out aggregated counts in the end

That said, the results I got from it so far look quite usable.

It's unlikely that I'll have much time to work on this and develop it into a fully-fledged solution.

I wanted to share what I have in case it's useful for others, or in case someone feels inspired to take the idea and develop it further.

Usage:

  JSONNET_STACK_PROFILE=stacks.out jsonnet main.jsonnet
  cat stacks.out | flamegraph.pl --hash > flamegraph.svg
@google-cla google-cla bot added the cla: yes label Apr 23, 2021
@sbarzowski
Copy link
Collaborator

This is very interesting. I was thinking about doing something like that myself, but didn't have much time recently.

I'd like to refactor it slightly (eliminate globals, extract all profiling logic to a separate function, so that in the normal flow it's just one check and one function call). Otherwise it looks good.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants