' the length setter could easily be used to pre-set the size for consecutive writes' I can't remember whether it was you or me who added this, but one of us probably went through similar thoughts previously and settled on the growBuffer method as another useful option: https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as#L876
btw, a quick scan of the code let me find something that is an obvious typo (mine I expect) https://github.com/apache/royale-asjs/blob/develop/frameworks/projects/Core/src/main/royale/org/apache/royale/utils/BinaryData.as#L170 you might want to fix that if you're still 'in the code'. On Mon, Jun 25, 2018 at 10:27 AM Harbs <[email protected]> wrote: > > > 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
