Profile Node.js in Flame IDE with CPU flame graphs, top functions, source hot lines, and heap snapshot comparisons. Give measured hotspots to an AI agent.
Flame's Profiler workspace with sample CPU profile data. New CPU and heap captures require a supported live debug session. Select the image to enlarge.
WHY IT HELPS
Follow the evidence before changing the implementation.
A slow request can come from computation, allocation, or waiting on something outside the process. Flame's Node profiler helps investigate the CPU and memory parts of that question from the same workspace as the source. Capture a representative workload, inspect sampled stacks and function costs, and use that evidence to choose a focused optimization. Record again after the change to check whether it helped.
See the CPU work in context
Explore the flame graph, zoom into a stack, search functions, or switch to Top functions. Distinguish a wide parent stack from time spent in the function itself before deciding what to rewrite.
Move from a capture to its source
Open source locations from the profile and use hot-line annotations where source mapping is available. Give the heaviest functions to an agent through Optimize with agent, then review its proposed change against the capture.
Compare memory observations
Take heap snapshots and compare constructor-level object counts and size summaries across captures. Use growth as a lead for investigation; an increasing bucket alone does not prove a leak.
HOW TO USE IT
A repeatable Node performance investigation.
Start a supported Node debug session
Use Flame's built-in Node debugger for the project and confirm that the process is running or paused. CPU and heap controls become available only when that live session advertises the corresponding profiling capability.
Record a representative workload
Open Profiler, choose Record CPU, reproduce the slow action, and stop the recording. Keep the input, request volume, warm-up, and workload duration consistent enough to repeat the experiment.
Inspect stacks and memory separately
Explore the flame graph and top functions to find expensive paths. Open source locations and enable hot lines when useful. For a memory question, take heap snapshots around a repeatable workload and compare object count and size changes by constructor.
Change one cause and measure again
Make a focused change manually or ask an agent to work from the profile context. Run correctness tests, then repeat the original workload. Compare captures and application measurements before concluding that the optimization improved the problem.
REQUIREMENTS & LIMITS
Know what the tool depends on.
This Node workflow uses a supported live session from Flame's built-in Node debugging engine. A terminal process or arbitrary debug adapter is not automatically a compatible profiling target.
CPU profiles are sampled observations of a recording window. A flame graph is not a chronological request trace, and CPU samples do not explain every source of I/O latency.
Heap capture can interrupt the target and consumes resources. Start with a representative development process. Constructor-level snapshot summaries are investigation aids, not an automatic memory-leak diagnosis.
Source navigation and hot lines depend on usable source locations and mappings. An AI optimization suggestion still needs correctness tests and a repeated performance measurement.
FAQ
Node.js Profiler: common questions
Yes. Start a supported live session with the built-in Node debugger, then use Record CPU in Profiler or the Debug panel. Reproduce the workload and stop the capture to inspect it.
The selected project needs a live compatible debug session that exposes the relevant capability. Check the project, debugging engine, and session state before recording.
A wide stack can include work performed by its descendants. Inspect both the call path and the function's own cost, and use Top functions to compare the sampled work before choosing an optimization.
Optimize with agent prepares the heavy-function context for an AI conversation. Review the resulting code, run tests, and record the same workload again to verify the effect.
No. Growth across constructor-level summaries can suggest where to investigate, but caches, expected retained state, and workload differences can also explain it. Repeat the observation and investigate object ownership.