-
Notifications
You must be signed in to change notification settings - Fork 445
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
fix: performance bottleneck in stat.js #463
Conversation
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
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 looks good. A side effect of disabling stats would be that the connection manager won't have any idea of what priority connections should be pruned if limits are exceeded. For use cases where connection limits aren't really going to be an issue (fixed connections) there shouldn't be any ill effect of disabling stats.
I would be open to a PR that allows disabling stats.
Thanks for the swift response and merge. I didn't realize Stats was load bearing, then perhaps it is wiser to make some of the heavier features configurable at least. Btw, yesterday it looked like the Windows tests were failing due to this change, but now they look fine. Any idea what happened? |
Yeah, Stats definitely needs some love. We're going to be working on the Connection Manager soon and will hopefully work out a minimum set of needed stats (if any) that are required for it to manage connections properly. From there we can shut everything else off by default I think.
I should have mentioned I reran them. Due to some timing issues on the windows CI environment the tests can be flakey for stats with when they are checked. I'm planning to get that resolved when I go through it as part of the async refactor in the next couple of weeks. |
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async await examples/echo * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async-await example chat * fix: move handler before start * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example * chore: remove unused vars
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async await examples/echo * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async-await example chat * fix: move handler before start * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example * chore: remove unused vars
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async await examples/echo * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example
* fix: performance bottleneck in stat.js (#463) Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU. * docs(fix): correct docs and example for pnet (#464) * docs(fix): correct docs and example for pnet * docs(fix): correct pnet docs * docs(fix): update README.md language (#468) * docs: reciprocate (#474) * docs(example): fix ipfs cat (#475) `ipfs.files.cat` is incorrect. the correct function is `ipfs.cat` * fix: async-await example chat * fix: move handler before start * fix: examples readme typos (#481) * fix: simplify libp2p bundle for echo example * chore: remove unused vars
Array.shift seems to be very slow, perhaps linear, on some engines, resulting in _update consuming a lot of CPU.
I transferred a large payload of 2.4GB between two machines running Node 12 on a local network and attached a Chrome profiler which showed a hotspot on the target machine of about 15s in this single line of code (the shift operation). The total transfer time was about 45s.
The CPU consumption was so high that the target machine was not able to consume the stream as new data was received, resulting in the TCP window filling up and causing network congestion. This was at speeds around 60MB/s on a high end MBP.
After this change, the time for the loop was down to about 1s. This might sound like a big improvement but 1s is still a lot for stats that are not important to all clients; perhaps consider allowing an option for turning stats off completely.