You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As previously mentioned on #148 a lot of work was done on CPU Profiler.
The only tool for profiling NodeJS cross-platform is the usage of Profiler.start and Profiler.stop. However, this dynamic instrumentation blocks the event-loop because it needs to iterate over all functions to map. (CpuProfiler::StartProfiling more specifically) and it is harmful to production environments.
This issue is to discuss some ways to improve these usages in the production environment.
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
======= iteration number 1 for node v16.15.1 ========
enable: 0.235ms
start: 1.483s
stop: 900.975ms
======= iteration number 2 for node v16.15.1 ========
enable: 0.238ms
start: 1.449s
stop: 911.747ms
======= iteration number 3 for node v16.15.1 ========
enable: 0.255ms
start: 421.201ms
stop: 240.386ms
======= iteration number 4 for node v16.15.1 ========
enable: 0.235ms
start: 1.474s
stop: 908.485ms
======= iteration number 5 for node v16.15.1 ========
enable: 0.237ms
start: 99.483ms
stop: 25.386ms
======= iteration number 6 for node v16.15.1 ========
enable: 11.825ms
start: 41.66ms
stop: 0.748ms
======= iteration number 7 for node v16.15.1 ========
enable: 0.251ms
start: 101.609ms
stop: 28.143ms
======= iteration number 8 for node v16.15.1 ========
enable: 0.233ms
start: 1.455s
stop: 899.074ms
======= iteration number 9 for node v16.15.1 ========
enable: 0.241ms
start: 103.015ms
stop: 27.097ms
======= iteration number 10 for node v16.15.1 ========
enable: 0.249ms
start: 101.046ms
stop: 24.36ms
======= iteration number 1 for node v18.4.0 ========
enable: 0.246ms
start: 354.838ms
stop: 207.19ms
======= iteration number 2 for node v18.4.0 ========
enable: 0.234ms
start: 101.858ms
stop: 21.897ms
======= iteration number 3 for node v18.4.0 ========
enable: 0.271ms
start: 1.442s
stop: 873.228ms
======= iteration number 4 for node v18.4.0 ========
enable: 0.237ms
start: 98.99ms
stop: 24.871ms
======= iteration number 5 for node v18.4.0 ========
enable: 0.235ms
start: 360.61ms
stop: 207.911ms
======= iteration number 6 for node v18.4.0 ========
enable: 0.249ms
start: 101.585ms
stop: 29.675ms
======= iteration number 7 for node v18.4.0 ========
enable: 0.239ms
start: 352.201ms
stop: 204.73ms
======= iteration number 8 for node v18.4.0 ========
enable: 0.233ms
start: 1.404s
stop: 865.165ms
======= iteration number 9 for node v18.4.0 ========
enable: 0.255ms
start: 362.245ms
stop: 200.001ms
======= iteration number 10 for node v18.4.0 ========
enable: 0.234ms
start: 102.054ms
stop: 26.845ms
There are several variables that might affect this benchmark such as page faults and so on. Nevertheless, I think the results in the latest version are acceptable
There are several variables that might affect this benchmark such as page faults and so on. Nevertheless, I think the results in the latest version are acceptable
For my personal culture: if you could share more information regarding stuff I should avoid when I write a benchmark it should be great :)
Activity
mmarchini commentedon Nov 25, 2020
Removing from the agenda until we come up with benchmarks for the performance issue.
github-actions commentedon Feb 24, 2021
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
RafaelGSS commentedon Jun 27, 2021
I've tried to reproduce this behavior but it looks like was fixed on v14 and above.
Code:
v10
v12
v14
v16
@Flarna I'm tagging you because I've seen your code example from: #148 (comment)
RafaelGSS commentedon Jun 30, 2021
We discussed and sounds reasonable to close this issue since the results look good for the production environment.
lastquestion commentedon Mar 16, 2022
Hi, @RafaelGSS,
can we reopen this issue? I ran the above bench program in
node: 16.14.0, latest LTS inv16as of today, and I got very slowstop()performance:v16.14.0yet on
node 14.18.2andnode 17.7.1, it looks like this:I went backwards on 16 LTS, and it's fast - sometimes - on
16.1.4.0:and it appears always fast, but not as fast as 14 or 17, on
16.10.0These were all run on a macbook pro 2020, intel.
RafaelGSS commentedon Mar 16, 2022
Hey! Are you able to send a reproducible code?
lastquestion commentedon Mar 16, 2022
Yes, I ran the exact script referenced above that you posted from the original thread.
I did not attempt to repro this on other machines / OS, only on mac (Big Sur). I didn't try on linux, for example.
RafaelGSS commentedon Mar 16, 2022
Oh, ok. I'll check soon
github-actions commentedon Jun 15, 2022
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
RafaelGSS commentedon Jun 15, 2022
Recently, I had no time to validate it. Does anyone in @nodejs/diagnostics interested in this discovery?
tony-go commentedon Jun 15, 2022
If I got it right, we should understand why the profiler takes too much to stop on Node 16.x and 17.x?
RafaelGSS commentedon Jun 15, 2022
Checking how much time is it taking in all Node.js versions would be a great start.
tony-go commentedon Jun 16, 2022
Neat! I could give it a try ^^. Feel free to share any resource that could help me.
I remember you posted that: https://github.com/RafaelGSS/nodejs-bench-operations
Could I use a similar approach?
RafaelGSS commentedon Jun 17, 2022
I think the snippet I sent above would work as well. #444 (comment)
tony-go commentedon Jun 22, 2022
Hey 👋
Make a simple script and put the results here: https://github.com/tony-go/v8-profiler-performance
What I did:
I keep the same output but let me know if you prefer a table with average etc...
Sorry if it looks a bit bikeshed, but it's my first time ^^
RafaelGSS commentedon Jul 1, 2022
Thank you @tony-go.
I've run it locally and the max spike I got was 1.5sec
There are several variables that might affect this benchmark such as page faults and so on. Nevertheless, I think the results in the latest version are acceptable
RafaelGSS commentedon Jul 1, 2022
@lastquestion I'll close it. In case you think this need to be fixed, please provide a bit more information of your use case. Thank you!
tony-go commentedon Jul 1, 2022
Good :)
For my personal culture: if you could share more information regarding stuff I should avoid when I write a benchmark it should be great :)