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
{{ message }}
Repository navigation
util.inspect is not so hot on large typed arrays #3648
... leads to death and sorrow, as the interpreter decides to util.inspect(x).
There are, of course, workarounds, such as
> x=new Float32Array(100000); 0
... but I was wondering if we might be able to do better.
What if we told util.inspect to handle ArrayBuffers and their views a bit differently from other objects?
Now obviously we don't want to go changing the code for util.inspect any time some new-fangled object that comes on the scene. However, typed arrays are definitely here to stay and currently growing in popularity.
Yes, there's a compelling case to show ArrayBuffer objects the same way as Buffer objects. On the other hand, I wonder if the views (e.g. Float32Array) have a little extra stuff that might be worth printing (e.g. the byteOffset, the length).
Aside, typed array / arraybuffer formatting was changed recently in commit 34a3591 and it also made rendering approximately three times faster.
Yes, the difference is really noticeable and array gets logged much faster. The output now is identical to new Array(X). @jacksonloper do you think this issue should still be addressed?
Nice work @bnoordhuis. It seems that you've done half the work!
However, I do think the work is not quite done. I, at least, am convinced that we definitely need to have some way of truncating very large typed arrays.
Why?
Short answer: because nobody wants to see a million elements printed, no matter how efficiently -- and a million-element typed array is not uncommon. Whereas a million-element Array object is always a terrible terrible idea.
Long answer: because typed arrays are really different from arrays. They're much closer to Buffer objects. I note that @vkurchatkin's initial expectation was that, in fact, they would be rendered like buffer objects (i.e. <Buffer c0 60 0a ... >), which is very similar to what @vdemedes proposed. Put that intuition together with using showHidden to permit diagnostics on the byte offset, etc, and I feel like you get something reasonable.
But I may be wrong! :)
It's tricky, because we have two competing things: Arrays look one way, Buffers look another way, TypedArrays are in-between. Personally I'm happy with @vdemedes compromise.
@jacksonloper I kind of changed my mind about this. This would be appropriate for ArrayBuffer, but typed arrays are typed for a reason so we should display elements accordingly
Cool. It seems to me that @vdemedes proposal is exactly in line with this idea: render typed array objects exactly like a Buffer, but be explicit about the type and render each element accordingly (i.e. don't render new Float32Array(1.0) as the underlying bytes, 00 00 80 3f)
#6334 Landed resolving the out of memory error. This does not completely resolve this issue, however, since the TypedArrays are still rendered the same as Arrays and not Buffers.
Activity
vkurchatkin commentedon Nov 3, 2015
Makes sense to show typed arrays the same way as buffers
jacksonloper commentedon Nov 3, 2015
Yes, there's a compelling case to show ArrayBuffer objects the same way as Buffer objects. On the other hand, I wonder if the views (e.g. Float32Array) have a little extra stuff that might be worth printing (e.g. the byteOffset, the length).
vadimdemedes commentedon Dec 3, 2015
How about displaying this, when array has more than X (for example, 10) elements (
new Float32Array(11):with
{ showHidden: true }:Although I also like 2nd option proposed by @jacksonloper.
jacksonloper commentedon Dec 3, 2015
Great!
bnoordhuis commentedon Dec 3, 2015
That would be somewhat incongruent with how arrays are displayed.
Aside, typed array / arraybuffer formatting was changed recently in commit 34a3591 and it also made rendering approximately three times faster.
vadimdemedes commentedon Dec 3, 2015
Yes, the difference is really noticeable and array gets logged much faster. The output now is identical to
new Array(X). @jacksonloper do you think this issue should still be addressed?jacksonloper commentedon Dec 3, 2015
Nice work @bnoordhuis. It seems that you've done half the work!
However, I do think the work is not quite done. I, at least, am convinced that we definitely need to have some way of truncating very large typed arrays.
Why?
Short answer: because nobody wants to see a million elements printed, no matter how efficiently -- and a million-element typed array is not uncommon. Whereas a million-element Array object is always a terrible terrible idea.
Long answer: because typed arrays are really different from arrays. They're much closer to Buffer objects. I note that @vkurchatkin's initial expectation was that, in fact, they would be rendered like buffer objects (i.e.
<Buffer c0 60 0a ... >), which is very similar to what @vdemedes proposed. Put that intuition together with usingshowHiddento permit diagnostics on the byte offset, etc, and I feel like you get something reasonable.But I may be wrong! :)
It's tricky, because we have two competing things: Arrays look one way, Buffers look another way, TypedArrays are in-between. Personally I'm happy with @vdemedes compromise.
vkurchatkin commentedon Dec 3, 2015
@jacksonloper I kind of changed my mind about this. This would be appropriate for
ArrayBuffer, but typed arrays are typed for a reason so we should display elements accordinglyjacksonloper commentedon Dec 3, 2015
Cool. It seems to me that @vdemedes proposal is exactly in line with this idea: render typed array objects exactly like a Buffer, but be explicit about the type and render each element accordingly (i.e. don't render
new Float32Array(1.0)as the underlying bytes,00 00 80 3f)jasnell commentedon May 3, 2016
#6334 Landed resolving the out of memory error. This does not completely resolve this issue, however, since the TypedArrays are still rendered the same as Arrays and not Buffers.
bnoordhuis commentedon Feb 7, 2017
@jasnell What remains to be done? I don't think we've received any complaints about how typed arrays are displayed nowadays so I move to close.
jasnell commentedon Feb 7, 2017
Agreed. If no one is complaining then we should be good