> On Jun 25, 2018, at 12:24 AM, Greg Dove <[email protected]> wrote: > > I don't expect things to change I guess, but it would theoretically be > better testing with the compiled version of BinaryData. Things like the > function call overhead from getTypedArray() vs. referencing something > directly and the repeated_position++ versus one _position op to increment > (e.g. for DataView) in some cases mean there is more work at the byte > level. But I don't expect this to change things based on these tests.
I had the same thoughts, and I’d be interested in seeing more test results. I briefly attempted using the code here https://github.com/jDataView/jDataView/blob/master/src/jdataview.js <https://github.com/jDataView/jDataView/blob/master/src/jdataview.js> for floats and doubles, but I had some trouble getting correct results. I someone has the time to add tests for different methods for floating point numbers, that should be a useful exercise. > Maybe I can troubleshoot the MD5 thing in the coming weeks. One of the > other things I wondered about for BinaryData is whether it should have it's > own 'autogrow' strategy internally for the buffer with sequential writes. > This is not really PAYG though, so I guess not. It definitely performs much > better on writing with a preallocated buffer length, so maybe that is the > recommended approach for users. I had similar thoughts, but the length setter could easily be used to pre-set the size for consecutive writes. This should give users the ability to implement relatively cheap writes. Possibly the most efficient way would be to instantiate an BinaryData with an ArrayBuffer of a set size. Thanks, Harbs
