buffer: added Buffer methods to r/w 24 bits integers.

[rootslab]

Added readInt24LE() readInt24BE(), readUInt24LE(), readUInt24BE(), writeInt24LE() writeInt24BE(), writeUInt24LE(), writeUInt24BE().
Added tests.

[rootslab]

I have seen readUIntLE/readUIntBE/readIntUE.. methods, but I think it could be simpler (also faster) to have direct methods to read/write at least 24 bits / 3 bytes integers.
Why don't use direct methods also for 40 to 48 bits, it is a problem of code style/size/repetition?

@trevnorris @bnoordhuis if the PR sounds good, I can do another PR with updated docs.

[trevnorris]

Performance difference is on the order of sub 10 ns. I don't think adding additional methods to Buffer is really necessary.

[rootslab]

Hi @trevnorris, Thanks for you reply.
My real point/intention is only to have direct API methods to read/write 24bits ints, "faster" is between () , because I know that speed is only a feature.

However, generally I deal with big Buffers ( > 1MB), you can see that exists a real gain (not ns), here a gist to run; see results, when the Buffer is small, improvements are not tangible, I agree, but if you deal a lot with bigger Buffers you can see a real difference in the long run. I see a gain up to 40% (then seconds).

P.S. The real difference is in writing Buffers, Sorry, I forget to mention write methods in the commit message!

[rootslab]

@trevnorris , As a last resort, can I appeal to Ecology?
Consume less CPU cycles! :DD

[yorkie]

@rootslab what protocol do you implement by using 3 bytes

[rootslab]

Hi @yorkie, thanks for your interest, simply, I read/write big chunks of values through Buffers.
I think I will publish some repos in the next weeks that deals with it.
However, no matter, I close the PR, I agree with @trevnorris, it's not so important. ;)

[algesten]

@yorkie one thing that comes to mind is 24-bit audio. but then i'm not sure how people typically organise that kind of information in memory and on disk.

[trevnorris]

@rootslab I appreciate the insight, and I think there's probably a fast-path that can be managed in the general implementation for 24-bit. I mean, honestly, is there really a use case for 40/48 bit reads/writes? I just did it because it could be done. :P

That being said, I'll look into how to speed up the generalized case. Thanks for your PR, and more so for validation that 24 bit reads/writes are actually used.

[rootslab]

Hi @trevnorris, the only way that comes to my mind, to improve speed for generalized code, is to use an array to cache multipliers values from 1 to 6 bytes, but I think that you wouldn't like to use an array inside Buffer code, right?

[trevnorris]

@rootslab Also can do something as simplistic as:

if (byteLength === 3)
  return ((this[offset]) |
      (this[offset + 1] << 8) |
      (this[offset + 2] << 16));

[rootslab]

@trevnorris, ok, now I understand what you mean, you propose a test condition only for 24 bits in the generalized code, I agree with you ;)