FWIW, Royale is about choices, so having a GrowableBinaryData as well as BinaryData is a fine thing to do.
AIUI, browsers are always fiddling with runtime optimizations and there are some amazing JIT implementations being worked on. Some implementations I've been told about trigger after a certain number of loops so sometimes you can get non-linear results as the number of loops increases. I don't know for sure that browsers are this smart, but I wouldn't be surprised if they are. Entire functions can get inlined, and some implementations can detect loops that are not obvious. HTH, -Alex On 6/24/18, 3:42 PM, "Greg Dove" <[email protected]> wrote: ' 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FCore%2Fsrc%2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Futils%2FBinaryData.as%23L876&data=02%7C01%7Caharui%40adobe.com%7C3aa5eb1379604801480e08d5da23b817%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636654769312980516&sdata=69VryqsQlLsj74XbFLZ6Rru6DYtOG98p2KDxEPNcS1E%3D&reserved=0 btw, a quick scan of the code let me find something that is an obvious typo (mine I expect) https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fframeworks%2Fprojects%2FCore%2Fsrc%2Fmain%2Froyale%2Forg%2Fapache%2Froyale%2Futils%2FBinaryData.as%23L170&data=02%7C01%7Caharui%40adobe.com%7C3aa5eb1379604801480e08d5da23b817%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636654769312980516&sdata=63PbmLFIGRmuiFgmHhHUmDt3aOjsHB2PMt1er22jBDI%3D&reserved=0 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FjDataView%2FjDataView%2Fblob%2Fmaster%2Fsrc%2Fjdataview.js&data=02%7C01%7Caharui%40adobe.com%7C3aa5eb1379604801480e08d5da23b817%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636654769312980516&sdata=0OU%2BpzeSe9w4nx4gupaf5h33502ds%2FW1UvourKzrrX4%3D&reserved=0 < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FjDataView%2FjDataView%2Fblob%2Fmaster%2Fsrc%2Fjdataview.js&data=02%7C01%7Caharui%40adobe.com%7C3aa5eb1379604801480e08d5da23b817%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636654769312980516&sdata=0OU%2BpzeSe9w4nx4gupaf5h33502ds%2FW1UvourKzrrX4%3D&reserved=0> 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
