Turbopack trace: report total system memory#92428
Conversation
Tests Passed |
Merging this PR will not alter performance
Comparing Footnotes
|
Stats from current PR🟢 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (25 files)Files with changes:
View diffsapp-page-exp..ntime.dev.jsfailed to diffapp-page-exp..time.prod.jsfailed to diffapp-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsfailed to diffapp-page-tur..ntime.dev.jsfailed to diffapp-page-tur..time.prod.jsfailed to diffapp-page.runtime.dev.jsfailed to diffapp-page.runtime.prod.jsfailed to diffapp-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display pages-api-tu..ntime.dev.jsDiff too large to display pages-api-tu..time.prod.jsDiff too large to display pages-api.runtime.dev.jsDiff too large to display pages-api.ru..time.prod.jsDiff too large to display pages-turbo...ntime.dev.jsDiff too large to display pages-turbo...time.prod.jsDiff too large to display pages.runtime.dev.jsDiff too large to display pages.runtime.prod.jsDiff too large to display server.runtime.prod.jsDiff too large to display 📎 Tarball URL |
| cpu_cores = std::thread::available_parallelism() | ||
| .map(|n| n.get()) | ||
| .unwrap_or(0), | ||
| system_memory_mb = (total_memory_bytes() / (1024 * 1024)) as u32, |
There was a problem hiding this comment.
The as_u32 conversion here isn't doing anything? Isn't this just looking for a Display implementation or something?
| system_memory_mb = (total_memory_bytes() / (1024 * 1024)) as u32, | |
| system_memory_mb = (total_memory_bytes() / (1024 * 1024)), |
Stacked on top of #92427
Y'all can push back on this if it's too intrusive, but I think it'd be useful to know total system memory in the trace for debugging.
We already have libc as a nested dep in plenty of other crates, so it shouldn't regress build time.
cargo treeshows that 0.2.174 is the version used by everything else in our deps tree.On macOS, use
sysctlto fetch system memoryOn Linux, use procfs
On Windows, use GlobalMemoryStatusEx
All of these callsites could be extended to fetch memory pressure / swap usage as well, but those aren't necessarily useful in the initial trace because the server has just started.