镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

util.inspect is not so hot on large typed arrays #3648

Closed

Description

@jacksonloper

Typing...

> x=new Float32Array(100000);

... 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.

Two reasonable courses would be

 >  new Float32Array(36)
 [Float32Array: length 36]

or

> new Float32Array(36)
{ BYTES_PER_ELEMENT: 4,
  get: [Function: get],
  set: [Function: set],
  slice: [Function: slice],
  subarray: [Function: subarray],
  buffer: {slice: [Function: slice], byteLength:144}
  length: 36,
  byteOffset: 0,
  byteLength: 4 }

What do you think. Am I crazy?

Activity

  1. added
    utilIssues and PRs related to the built-in util module.
    feature requestIssues requesting new Node.js features.
    on Nov 3, 2015
  2. vkurchatkin commented on Nov 3, 2015

    @vkurchatkin
    Contributor

    Makes sense to show typed arrays the same way as buffers

  3. jacksonloper commented on Nov 3, 2015

    @jacksonloper
    Author

    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).

  4. vadimdemedes commented on Dec 3, 2015

    @vadimdemedes

    How about displaying this, when array has more than X (for example, 10) elements (new Float32Array(11):

    Float32Array [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... ]
    

    with { showHidden: true }:

    Float32Array [
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      0,
      ...,
      [BYTES_PER_ELEMENT]: 4,
      [length]: 11,
      [byteLength]: 44,
      [byteOffset]: 0,
      [buffer]: ArrayBuffer { byteLength: 44 } ]
    

    Although I also like 2nd option proposed by @jacksonloper.

  5. jacksonloper commented on Dec 3, 2015

    @jacksonloper
    Author

    Great!

  6. bnoordhuis commented on Dec 3, 2015

    @bnoordhuis
    Member

    Float32Array [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... ]

    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.

  7. vadimdemedes commented on Dec 3, 2015

    @vadimdemedes

    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?

  8. jacksonloper commented on Dec 3, 2015

    @jacksonloper
    Author

    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.

  9. vkurchatkin commented on Dec 3, 2015

    @vkurchatkin
    Contributor

    @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

  10. jacksonloper commented on Dec 3, 2015

    @jacksonloper
    Author

    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)

  11. jasnell commented on May 3, 2016

    @jasnell
    Member

    #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.

  12. bnoordhuis commented on Feb 7, 2017

    @bnoordhuis
    Member

    @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.

  13. jasnell commented on Feb 7, 2017

    @jasnell
    Member

    Agreed. If no one is complaining then we should be good

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.utilIssues and PRs related to the built-in util module.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions