Do you remember if you tried just pulling bytes one at a time? I think I did. But I would need to check an older machine at some point to see if I still have any evidence of this. I definitely recall a bit of head-scratching before I actually settled on that approach with the typed arrays, but perhaps I missed some other simpler option. Another thing I do recall was that using the DataView approach was faster on one of the other browsers (possibly Edge, not sure now), but sluggish particularly on Chrome.
I am not sure what the int16/int-aligned issue is yet (I have not read back through all the relevant history) but if we can set up a unit test for it, this stuff all becomes much clearer I think. I'd be happy to spend some more time on this during the coming weekend and see if I can dig up any extra info. "Royale is all about choices, so maybe there are some other data types we should provide for our users that do map cleanly to these typed arrays. " I viewed BinaryData as being largely 'ByteArray'-like, primarily to help with migrating legacy actionscript. I think there is definitely opportunity to make some things that are closer to the JS native classes, which makes sense particularly as people begin new projects with Royale and focus less on migrating legacy projects. Some simple approach to emulating the js native classes on the swf side is also an option at the lowest level, I guess. On Thu, Jun 21, 2018 at 10:14 AM Alex Harui <[email protected]> wrote: > Hi Greg, > > Good to know more about the background. Do you remember if you tried just > pulling bytes one at a time? > > For me, the key piece is that the int16s are not guaranteed to be > "int-aligned" in a true byte array so we have to give up on even > temporarily creating typed arrays to read the data. > > Royale is all about choices, so maybe there are some other data types we > should provide for our users that do map cleanly to these typed arrays. > > Thanks, > -Alex > > On 6/20/18, 2:45 PM, "Greg Dove" <[email protected]> wrote: > > Hi guys, some quick comments... > I do recall this being difficult to get a good balance of performance > whilst getting close to the ByteArray api. > I did do a reasonable amount of performance tests across multiple > browsers, > trying multiple approaches and I ended up choosing an implementation > that > favored performance in Chrome (as most 'popular' browser) and was not > always the best, but was certainly not the worst in other browsers. I > did > focus on speed and not memory though. > iirc the browser results were still slower than flash Bytearray native > performance on the same machine, but were still much faster than the > original method that was used before I made the original changes. > > Harbs, there is a very comprehensive set of unit tests for BinaryData. > I > have not looked at what the issue is that you are currently > addressing, but > they obviously did not include that - it would be good to add it to > them if > possible. They were part of the flexunit testing on the flash side, > but you > would need to use that manual unit testing setup that is in that manual > unit testing demo project (that you got working after we discussed at > one > point) to assess your changes to the js implementation. At the very > least, > right now, this should help to verify that all the methods that were > changed still give the correct results for a range of normal and edge > cases. > > Alex, the typed array instantiation issue is valid on looking at the > code, > but with all the optimizations in the js engines it is difficult to > know > whether things like this are actually 'real' in terms of impact in > actual > use because the engines are so smart at optimizing things at runtime. > As I > said, I did try multiple approaches, and I am sure I did not consider > all > options, but I certainly did have performance 'front and center' when I > worked on this, so spent a bunch of time looking at it. But probably > large > loop tests of the same method (which I was doing for performance > tests) are > also not representative of general use (and therefore perhaps the same > could apply to any 'runtime optimizations' by the engines if that is > happening). > > > On Thu, Jun 21, 2018 at 4:17 AM Harbs <[email protected]> wrote: > > > I expect the same. > > > > Harbs > > > > > On Jun 20, 2018, at 7:01 PM, Alex Harui <[email protected]> > > wrote: > > > > > > FWIW, I would expect that to be faster than creating new Typed > Arrays on > > each read. The Garbage Collection implications of an instantiation > on each > > read made me cringe. > > > > > > My 2 cents, > > > -Alex > > > > > > On 6/20/18, 1:31 AM, "Harbs" <[email protected] <mailto: > > [email protected]>> wrote: > > > > > > I ended up rewriting the read methods to use simple math and > shift > > operators. It reads bytes directly from the existing Uint8Array and > uses > > shift operators to convert unsigned ints to signed ones. Over-all > the new > > methods should be more robust and more efficient. > > > > > > There is likely still issues with the float read methods and all > > multi-byte write methods. > > > > > > Harbs > > > > > >> On Jun 19, 2018, at 9:28 PM, Harbs <[email protected]> wrote: > > >> > > >> DataView works in IE10+. The problem with DataView as that it’s > slow. > > >> > > >>> On Jun 19, 2018, at 9:24 PM, Carlos Rovira < > [email protected]> > > wrote: > > >>> > > >>> Hi Harbs, > > >>> > > >>> for me any improvement seems ok, just ensure it works in all > browsers > > >>> (specially IE11) > > >>> > > >>> thanks > > >>> > > >>> 2018-06-19 19:25 GMT+02:00 Alex Harui <[email protected] > >: > > >>> > > >>>> Isn't ByteArray mapped to UInt8Array? > > >>>> > > >>>> On 6/19/18, 10:07 AM, "Harbs" <[email protected]> wrote: > > >>>> > > >>>> BinaryData uses TypedArrays to read data. It seems that if the > > >>>> ArrayBuffer does not divide evenly into the target TypedArray, > you > > get a > > >>>> runtime error. > > >>>> > > >>>> For example: > > >>>> > > >>>> readShort() works like this: > > >>>> var ret:int = new Int16Array(ba, _position, 1)[0]; > > >>>> > > >>>> If _position is not divisible by 2 (i.e. an odd number), this > causes > > a > > >>>> RTE. > > >>>> > > >>>> readInt() has a similar problem that _position needs to be > divisible > > >>>> by 4, etc. > > >>>> > > >>>> Am I correct that Flash’s ByteArray works correctly in this > > situation? > > >>>> We can use DataViews to solve the problem or we can read the > bytes > > directly. > > >>>> > > >>>> Thanks, > > >>>> Harbs > > >>>> > > >>>> > > >>> > > >>> > > >>> -- > > >>> Carlos Rovira > > >>> > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a39e02d45a94743801a08d5d688429c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636650803077295693&sdata=po2u0k2cYHf2yvcfuYaN8VzEoF9pAzcV6YEPaS%2Be8G0%3D&reserved=0 > > < > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a39e02d45a94743801a08d5d688429c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636650803077295693&sdata=po2u0k2cYHf2yvcfuYaN8VzEoF9pAzcV6YEPaS%2Be8G0%3D&reserved=0 > > > > > > > >
