-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Application profiling #8695
Application profiling #8695
Conversation
9809022
to
66fffa1
Compare
I've finally gotten to addressing the PR feedback from late last year. The main changes have been:
What’s still missing:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😍
This will be a really useful feature! My only question is around naming. I'm not sure what "application" refers to here. It's not really profiling the user's application so much as it is profiling Parcel. It seems more like a "trace" to me. Maybe we could have |
Also rename: - @parcel/reporter-application-profiler -> @parcel/reporter-tracer - PluginApplicationProfiler -> PluginTracer - cli option `--profile-application` -> `--trace` - PluginOptions.applicationProfiler -> PluginOptions.tracer
Renamed ApplicationProfiler -> Tracer Also renamed:
|
@devongovett I think the rename is good, but with one small point of confusion: The |
That's not exposed externally to parcel though right? If not then doesn't seem like too big a deal. |
packages/core/workers/index.d.ts
Outdated
@@ -11,6 +11,7 @@ export type FarmOptions = { | |||
workerPath?: FilePath, | |||
backend: BackendType, | |||
shouldPatchConsole?: boolean, | |||
shouldProfileApplication?: boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldProfileApplication?: boolean, | |
shouldTrace?: boolean, |
@@ -74,6 +76,28 @@ export default async function babel7( | |||
}, | |||
}; | |||
|
|||
if (tracer.enabled) { | |||
config.wrapPluginVisitorMethod = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this wrap visiting each individual AST node, or just once for each plugin? How expensive is that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this wrap visiting each individual AST node, or just once for each plugin? How expensive is that?
I just ran two full production Jira builds back-to-back, one with tracing & one without (both with --no-cache
). The timings were 18m 29s without tracing, and 19m 1s with tracing (on an M1 Mac). So minimal overhead for tracing in general.
The trace file produced is approximately 1.4GB - can't load it directly in the Perfetto UI (the WASM version), but works fine via the trace_processor
CLI tool.
There are approximately 2.9m Babel transform entries - so yes, my understanding is that it wraps every visitor call for every AST type, but as you can see the overhead of this is relatively minimal.
↪️ Pull Request
This is an implementation of the Tracing RFC - more detail on the background and motivations is in #8588. The main differences from the RFC is that the feature is called "application profiling" (and the existing CPU profiling is referred to as "Sampling Profiling").
Instrumentation has been added for:
🚨 Test instructions
An app profile can be generated by starting Parcel with
--profile-application
.✔️ PR Todo
See also documentation PR: parcel-bundler/website#1075