Skip to content
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

Performance instrumentation #241

Closed
brson opened this issue Jan 5, 2013 · 3 comments
Closed

Performance instrumentation #241

brson opened this issue Jan 5, 2013 · 3 comments

Comments

@brson
Copy link
Contributor

brson commented Jan 5, 2013

We need to be able to make repeatable performance measurements of various kinds. There is very minimal code for this already in servo in the form of a time function, but we need much more. We want servo designed for gecko-style telemetry from the beginning, so it would serve us well to do some up-front investigation into what they are doing.

Some types of metrics we care about:

  • Speed of specific sections of code
  • Latency between two events
  • Memory usage of a task over time
  • Per-type memory usage

We need a reporting infrastructure that allows measurements to be reported and recorded in a structured way. We'll want to track metrics over time. I imagine having a global metrics task that dumps them to a database at shutdown.

For memory profiling in particular we'll want to make improvements to the Rust runtime, at minimum we'll want a way to give tasks names, associate allocations with names of Rust types, and to be able to periodically interrogate the allocations of a task, maybe register for allocator events.

We'll also need a way to integrate our metrics with whatever metrics SpiderMonkey offers.

@atris
Copy link

atris commented Jan 15, 2013

The third point seems just like the project I did...Does it sound nice if I bring it to the latest tree and do the performance statistics? Because if we can do that, that will solve the third point.

The fourth point is what we were initially planning for extension on the memory watcher project.

The design seems pretty coherent.The global metrics task brings back some memories :)

We can get the function names through the LLVM call stack. memory watcher already gives the task Id,type and size of the memory allocated.

Second point can be solved by spawning two tasks for the two events been measured,and use time function to independently measure them.this needs more research.

Point one needs thinking.

Do we plan to interface it with telemetry in any way?

@brson
Copy link
Contributor Author

brson commented Jan 15, 2013

Yes, go ahead and measure the performance impact of your implementation. I don't know if gecko's telemetry is something we can interface with or just something to immitate - I don't know anything about it.

@mbrubeck
Copy link
Contributor

Servo now has various infrastructure for time and memory profiling.

jdm pushed a commit to jdm/servo that referenced this issue Mar 6, 2021
Use ccache

Not sure if this works.

r? @larsbergstrom

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/rust-mozjs/241)
<!-- Reviewable:end -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants