-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Performance regression with libxmljs #30995
Comments
I patched libxmljs2 to call Seems that calling |
benjamn
added a commit
to meteor/node-fibers
that referenced
this issue
Dec 30, 2019
Apparently calling v8::Isolate::AdjustAmountOfExternalAllocatedMemory frequently results in lots of wasted CPU cycles on garbage collection, per discussion here: meteor/meteor#10527 (comment) This fix was inspired by marudor/libxmljs2#22, which seems to have addressed nodejs/node#30995. Another project that benefitted from adjusting external allocated memory less often: mapnik/node-mapnik#136
benjamn
pushed a commit
to meteor/meteor
that referenced
this issue
Dec 30, 2019
Apparently calling v8::Isolate::AdjustAmountOfExternalAllocatedMemory frequently results in lots of wasted CPU cycles on garbage collection, per discussion here: #10527 (comment) This fix was inspired by marudor/libxmljs2#22, which seems to have addressed nodejs/node#30995. Another project that benefitted from adjusting external allocated memory less often: mapnik/node-mapnik#136
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not sure if this is an issue with node or libxmljs (which wraps the libxml2 library), but anyhow, here's a reduced test case of behavior I've observed. All test have been run on a Macbook Pro running macOS Catalina.
If I run this script on Node 11.15.0, 10.16.3 or 8.16.1 (with
--trace-gc
enabled), everything works as expected. Mark-sweep operations take approximately 10 milliseconds each.On Node 12, the following behavior can be observed.
The Mark-sweep operations now take over 80 second each and everything grinds to a halt. For what it's worth, I haven't been able to observe any memory leaks.
The time taken for each GC pause seems to be roughly proportional to the number of elements in the XML document.
I've tested and observed this on the following Node 12 versions: 12.0.0, 12.8.0 and 12.12.0.
Flame graphs captured with DTrace.
Node 12
![Node 12](https://camo.githubusercontent.com/85eec678d3ed7438386c401293b4286a3605f59dd5cd485b2ba9dbd45d52294c/68747470733a2f2f736c75756b6b6f6e656e2e66692f6f75742e737667)
Node 10
![Node 10](https://camo.githubusercontent.com/59cf59882c360dbd5751dd603aec0876aecb39b96f1132766e8b9c83bce2ecfe/68747470733a2f2f736c75756b6b6f6e656e2e66692f6f75745f6e6f646531302e737667)
The text was updated successfully, but these errors were encountered: