-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Initial tracing implementation #4966
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Ignored Deployments
|
✅ This change can build |
|
Linux Benchmark for 05f1b16Click to view benchmark
|
MacOS Benchmark for 05f1b16
Click to view full benchmark
|
Linux Benchmark for d510489Click to view benchmark
|
MacOS Benchmark for d510489
Click to view full benchmark
|
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.
Change the level of all spans and events here from Level::Info
to Level::Trace
.
turbo_tasks::macro_helpers::tracing::Instrument::instrument( | ||
async { | ||
let turbo_tasks_result = #original_function(#(#input_arguments),*).await; | ||
turbo_tasks::macro_helpers::notify_scheduled_tasks(); | ||
turbo_tasks_result | ||
}, | ||
turbo_tasks::macro_helpers::tracing::info_span!(#name_code) | ||
).await |
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.
Can we expose a turbo tasks API for this instead of doing this in the macro itself? We should strive to keep the macro output minimal.
e.g. turbo_tasks::macro_helpers::instrument!(#name_code, #original_function(#(#input_arguments),*))
Linux Benchmark for 8d89006Click to view benchmark
|
Linux Benchmark for 53a3b34Click to view benchmark
|
MacOS Benchmark for 53a3b34
Click to view full benchmark
|
### What? adds `NEXT_TURBOPACK_TRACING` env var to enable tracing. Writes into `.next/trace.log` There are 4 presets: * `NEXT_TURBOPACK_TRACING=overview` gives a overview of requests and modules processed. * `NEXT_TURBOPACK_TRACING=next` above plus details for next.js * `NEXT_TURBOPACK_TRACING=turbopack` above plus details for turbopack * `NEXT_TURBOPACK_TRACING=turbo-tasks` above plus details for turbo-tasks Published release builds will only allow `overview` to work, since all detailed instrumentation is statically disabled. see vercel/turborepo#4966 for more details ### Why? get more insight into build times ### Turbopack changes * vercel/turborepo#4995 * vercel/turborepo#5049 * vercel/turborepo#5053 * vercel/turborepo#4966
### What? adds `NEXT_TURBOPACK_TRACING` env var to enable tracing. Writes into `.next/trace.log` There are 4 presets: * `NEXT_TURBOPACK_TRACING=overview` gives a overview of requests and modules processed. * `NEXT_TURBOPACK_TRACING=next` above plus details for next.js * `NEXT_TURBOPACK_TRACING=turbopack` above plus details for turbopack * `NEXT_TURBOPACK_TRACING=turbo-tasks` above plus details for turbo-tasks Published release builds will only allow `overview` to work, since all detailed instrumentation is statically disabled. see vercel/turborepo#4966 for more details ### Why? get more insight into build times ### Turbopack changes * vercel/turborepo#4995 * vercel/turborepo#5049 * vercel/turborepo#5053 * vercel/turborepo#4966
### Description * adds a raw_trace subscriber that will emit the raw trace events into `.turbopack/trace.log` (resp. `.next/trace.log` for next.js) * adds a CLI script which converts the raw trace into a chrome trace json file -> https://ui.perfetto.dev/ * adds a `TURBOPACK_TRACING` (resp. `NEXT_TURBOPACK_TRACING`) env var to enable tracing * adds some presets e. g. `turbopack` or `next` to enable tracing for certain things. * add tracing for invalidations There are three different visualization modes: #### `--single` Shows all cpu time as it would look like when a single cpu would execute the workload. (10 concurrent tasks that take 1s are shown as 10 tasks that take 1s with total time of 10s) Pro: * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Total time won't be represented correctly, since a single CPU would take longer Use Case: Gives a good overview of slow tasks in a build. #### `--merged` Shows all cpu time scaled by the concurrency. (10 concurrent tasks that take 1s are shown as 10 tasks that take 0.1s with total time of 1s) Pro: * Total time is represented correctly * Low concurrent tasks are bigger * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Individual tasks time won't be represented correctly. Use Case: Gives a good overview why a build is slow overall. #### `--threads` Shows cpu time distributed on infinite virtual cpus/threads. (10 concurrent tasks that take 1s are shown as 10 concurrent tasks that take 1s with total time of 1s) Pro: * Concurrency is shown via multiple CPU * Most realistic visualization Con: * Hard to read
### Description * adds a raw_trace subscriber that will emit the raw trace events into `.turbopack/trace.log` (resp. `.next/trace.log` for next.js) * adds a CLI script which converts the raw trace into a chrome trace json file -> https://ui.perfetto.dev/ * adds a `TURBOPACK_TRACING` (resp. `NEXT_TURBOPACK_TRACING`) env var to enable tracing * adds some presets e. g. `turbopack` or `next` to enable tracing for certain things. * add tracing for invalidations There are three different visualization modes: #### `--single` Shows all cpu time as it would look like when a single cpu would execute the workload. (10 concurrent tasks that take 1s are shown as 10 tasks that take 1s with total time of 10s) Pro: * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Total time won't be represented correctly, since a single CPU would take longer Use Case: Gives a good overview of slow tasks in a build. #### `--merged` Shows all cpu time scaled by the concurrency. (10 concurrent tasks that take 1s are shown as 10 tasks that take 0.1s with total time of 1s) Pro: * Total time is represented correctly * Low concurrent tasks are bigger * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Individual tasks time won't be represented correctly. Use Case: Gives a good overview why a build is slow overall. #### `--threads` Shows cpu time distributed on infinite virtual cpus/threads. (10 concurrent tasks that take 1s are shown as 10 concurrent tasks that take 1s with total time of 1s) Pro: * Concurrency is shown via multiple CPU * Most realistic visualization Con: * Hard to read
### Description * adds a raw_trace subscriber that will emit the raw trace events into `.turbopack/trace.log` (resp. `.next/trace.log` for next.js) * adds a CLI script which converts the raw trace into a chrome trace json file -> https://ui.perfetto.dev/ * adds a `TURBOPACK_TRACING` (resp. `NEXT_TURBOPACK_TRACING`) env var to enable tracing * adds some presets e. g. `turbopack` or `next` to enable tracing for certain things. * add tracing for invalidations There are three different visualization modes: #### `--single` Shows all cpu time as it would look like when a single cpu would execute the workload. (10 concurrent tasks that take 1s are shown as 10 tasks that take 1s with total time of 10s) Pro: * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Total time won't be represented correctly, since a single CPU would take longer Use Case: Gives a good overview of slow tasks in a build. #### `--merged` Shows all cpu time scaled by the concurrency. (10 concurrent tasks that take 1s are shown as 10 tasks that take 0.1s with total time of 1s) Pro: * Total time is represented correctly * Low concurrent tasks are bigger * Concurrency is visualized by bar filling (dark filled bars -> too few concurrency) * It injects pseudo bars with "cpus idle" for low concurrency (with `--idle`) Con: * Individual tasks time won't be represented correctly. Use Case: Gives a good overview why a build is slow overall. #### `--threads` Shows cpu time distributed on infinite virtual cpus/threads. (10 concurrent tasks that take 1s are shown as 10 concurrent tasks that take 1s with total time of 1s) Pro: * Concurrency is shown via multiple CPU * Most realistic visualization Con: * Hard to read
Description
.turbopack/trace.log
(resp..next/trace.log
for next.js)TURBOPACK_TRACING
(resp.NEXT_TURBOPACK_TRACING
) env var to enable tracingturbopack
ornext
to enable tracing for certain things.There are three different visualization modes:
--single
Shows all cpu time as it would look like when a single cpu would execute the workload.
(10 concurrent tasks that take 1s are shown as 10 tasks that take 1s with total time of 10s)
Pro:
--idle
)Con:
Use Case: Gives a good overview of slow tasks in a build.
--merged
Shows all cpu time scaled by the concurrency.
(10 concurrent tasks that take 1s are shown as 10 tasks that take 0.1s with total time of 1s)
Pro:
--idle
)Con:
Use Case: Gives a good overview why a build is slow overall.
--threads
Shows cpu time distributed on infinite virtual cpus/threads.
(10 concurrent tasks that take 1s are shown as 10 concurrent tasks that take 1s with total time of 1s)
Pro:
Con: