-
Notifications
You must be signed in to change notification settings - Fork 29.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
util.inspect is slow for large sparse arrays #14487
Comments
BTW, v4.8.4 just crashes after some seconds: Output:> node.4.8.4.v8-4.5.exe
> Array(100000000)
<--- Last few GCs --->
48905 ms: Scavenge 1165.3 (1212.7) -> 1165.3 (1212.7) MB, 0.4 / 0 ms (+ 40.0 ms in 1 steps since last GC) [allocation failure] [incremental marking delayingmark-sweep].
49298 ms: Mark-sweep 1165.3 (1212.7) -> 577.9 (616.7) MB, 393.3 / 0 ms (+ 79.0 ms in 10 steps since start of marking, biggest step 40.0 ms) [last resort gc].
49638 ms: Mark-sweep 577.9 (616.7) -> 577.9 (615.7) MB, 340.0 / 0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000002CAB57373A9 <JS Object>
2: formatArray(aka formatArray) [util.js:~510] [pc=000002C888C383BE] (this=000002CAB5704131 <undefined>,ctx=000002CAB57F93E1 <an Object with map 0000005B2F645AD1>,value=000002CAB57F93C1 <JS Array[100000000]>,recurseTimes=2,visibleKeys=000002CAB57F9389 <an Object with map 0000005B2F6065C9>,keys=000002CAB57FE441 <JSArray[0]>)
3: formatValue(aka formatValue) [util.js:447] [pc=000002C888...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
|
v6.11.1 returns immediately: Output:> node.6.11.1.v8-5.1.exe
> Array(100000000)
[ ,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
... 99999900 more items ] |
Possible cause: #11576 |
indeed. Versions of node before #11576 examined only the first 100 array elements; with the change they do 100 million The
|
Would it be better to iterate over keys instead, avoiding linear-time complexity at all? 1e8 was just an example, but it practice the length could easily be larger (up to 232-1). |
@not-an-aardvark using Object.keys is bad for the average case where arrays do not contain huge holes. |
That makes sense (it would result in a new large array being generated in the common case, even when only the first 100 elements will be displayed). For what it's worth, iterating over the array with a for-in loop would solve both issues. I don't think removing the |
correct, The code already fetches the
Edit: actually, the |
@andrasq that is true and I realized that as well when looking at the code but it is actually bad that Object.keys is used as it is not necessary for arrays when using |
* improve util.inspect performance This is a huge performance improvement in case of sparse arrays when using util.inspect as the hole will simple be skipped. * use faster visibleKeys property lookup * add inspect-array benchmark PR-URL: #14492 Fixes: #14487 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Array(100000000)
After about 15 seconds,
[ <100000000 empty items> ]
is printed.In contrast, entering the same thing into the Chrome devtools console results in an output almost immediately.
It looks like this happens because
util.inspect
iterates from 0 toarray.length
. It might be better to iterate overObject.keys(array)
instead.The text was updated successfully, but these errors were encountered: