This fixes about 130 clippy lints. Let me know if i should split up the commit.
I wasn't sure about some of the changes, especially map_or instead of map(...).unwrap_or(...) and if let instead of single arm match were not always a strict improvement in my opinion, but i'll leave that decision to the reviewer :)
There are about 150 lints left which i thought were clippy bugs or i didn't know how to fix.
cc @Manishearth
Source-Repo: https://github.com/servo/servo
Source-Revision: 9da739acefc7d1776bf727c8bf782eb79f241028
Multiprocess mode is enabled with the `-M` switch, and sandboxing is
enabled with the `-S` switch.
Rebase of #6884.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8b39b9afed6ef8a3d7d3e6609fd301a37825d3e1
This is a fix for #8468.
Currently XHR timeouts schedule themselves for execution via `CommonScriptMsg::RunnableMsg`s. This was necessary when these timeouts used a separate thread to schedule themselves. Now it's a potential race that should have been eliminated as part of #8168.
Source-Repo: https://github.com/servo/servo
Source-Revision: 49d48a8680003267f29ebf8cd47c244b07f4c4d2
This is an rough solution to the issue described in #3396. XHRs still do their own thing and an overall clean up is in order. Before I do that, though, I'd really like someone to sign off on the overall idea.
There's one major difference to what jdm layed out #3396: The timers remain with the window/worker and only the earliest expiring one is coordinated with the dedicated timer thread.
That means both the timer thread and the window/worker have to keep track of which timer expires next, which feels a bit wonky. However, the upshot is that there's no need for communication with the timer thread when a pipeline is frozen, thawed or dropped.
Most relvant parts are
- the [`TimerScheduler`](6f5f661958 (diff-74137a6f50ab38e7a1e4d16920a66ce7R73)), which is the new per-constellation timer task and
- the [`ActiveTimers`](6f5f661958 (diff-86707d952414a2860b78bcf6c1db8e2eR34)) which is what's left on the window/worker side.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2de5407cdabef67ed03b2ad4edf4a22541d77875
Add the energy-profiling feature. Users can compile the proper (or their own) version of energymon libraries to capture power/energy data at runtime. The results are accessed through heartbeats.
Additionally, there are a couple of python scripts to enable heartbeats for profiler categories and process the results into some visualizations to help understand how time and energy is being spent in Servo.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7b6c341900a66d1177fdc3f46705e9fb07a5b1dc
The script crate had its own built-in profiling which was basically doing the same thing as the profile crate. This wraps the internal profiling around the main profile functionality. Script-related tasks are now added to the ProfilerCategory enum.
Source-Repo: https://github.com/servo/servo
Source-Revision: ca36779a7e8298918b21ae243a43a71b1520119b
Title sums it up. Time function in the time module of profile crate was unused.
Unless we plan to use it soon, we should clean it up
See issue #7501 related to it.
Thanks.
Source-Repo: https://github.com/servo/servo
Source-Revision: a58f71c38eb64a723cfa6f69c75c03e0d46c805e
This PR adds Heartbeats capability to servo. Heartbeats are used for detailed performance and power/energy profiling. We will add the power/energy readings in the future.
New dependencies are introduced which need in-depth reviews. I'm the only one who has had eyes on any of this, and I have limited resources for testing cross-platform compatibility.
* https://github.com/libheartbeats/heartbeats-simple - provides native C libraries from a shared code base:
* hbs[-static] - performance monitoring
* hbs-acc[-static] - performance with accuracy monitoring
* hbs-pow[-static] - performance with power/energy monitoring (the one we're using)
* hbs-acc-pow[-static] - performance with accuracy and power/energy monitoring
* https://github.com/connorimes/heartbeats-simple-sys provides rust wrappers for the native C libraries above - one crate for each + a common crate. These link with the *-static versions of the heartbeats libraries.
* https://github.com/connorimes/heartbeats-simple-rust provides rust abstractions over the -sys crates above - one crate for each.
The new `heartbeats` module in the `profile` crate looks for environment variables telling it to use heartbeats for each ProfilerCategory and where to put log files. (Of course, if somebody knows how to iterate over the enum instead of hardcoding each one, that would be fantastic.) If the environment variables aren't set for particular categories, heartbeats aren't created or used.
An interface change is made in the `profile_traits` crate to pass both the start and end time in a `ProfilerMsg` instead of just the elapsed time. Later we will add energy readings as well.
Source-Repo: https://github.com/servo/servo
Source-Revision: d89e4f7991a4e43f16ea57587004e3616addcc09
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: f778e0eecf7cd8a2b870d18c3c305ff10d6b1894
A rebuild after touching components/profile/mem.rs now takes 48 seconds (and
only rebuilds `profile` and `servo`) which is much lower than it used to be.
In comparison, a rebuild after touching components/profile_traits/mem.rs takes
294 seconds and rebuilds many more crates.
This change also removes some unnecessary crate dependencies in `net` and
`net_traits`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77f653da2c4120ea7ac1a946d97fc70059d513d4
- Most of util::memory has been moved into profile::mem, though the
`SizeOf` trait and related things remain in util::memory. The
`SystemMemoryReporter` code is now in a submodule
profile::mem::system_reporter.
- util::time has been moved entirely into profile::time.
Source-Repo: https://github.com/servo/servo
Source-Revision: d1268ec9c6633684270015e7b2619181aeb47b8b
