I remembered there were tests, but I forgot where. Thanks for that. I’ll try to ad a test for this...
FYI, the MD5 test there now fails. I have no idea why. Maybe I messed something up with my BinaryData changes, but I can’t see what… > On Jun 21, 2018, at 12:45 AM, 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 >>> >>
