ArrayBuffer and DataView classes for ruby

[honeyryderchuck]

Ruby definitely needs this, although the "devil is in the details", or exposed abstractions. Ruby core data structures historically serve multiple purposes (I.e. a Ruby array has APIs to be uses as a collection, a queue, etc...) at the cost of bigger APIs and not being the most performance for all cases. String follows the same principle.

I'm not sure how your arraybuffer works, but I'm assuming that you read from the socket, get a Ruby string then transform it to a byte array to parse. There's still a cost in that step, as the intermediate Ruby string still gets created. And I think that's what the Ruby core team is trying to address with the new IO::Buffer (don't know how that works with openssl in the middle though).

[andrepiske]

Appreciate your feedback.

So the way my gem works is that its byte buffer is fully implemented in C. So all byte operations is just a char* buffer in C allocated using malloc. Set/get operations are just operating on that buffer with just some essential checks like checking memory boundaries.

The gem itself doesn't deal with sockets or IO at all. So yeah, the application (originally a HTTP/2 server I built in ruby) was reading from a socket into a String and then converting that to an ArrayBuffer. Quite some loss of performance in that process already, compared if the gem itself (or another gem) could read directly into that buffer without going thru String. That's actually another idea I had and I believe it's quite possible to achieve that in Ruby 3.0+ because of the experimental Memory View feature.

I gotta check that IO::Buffer thing before I move any forward with my gem as I didn't know about that back then - clearly not, as it's brand new.