royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: BinaryData and odd bytes
Date Wed, 20 Jun 2018 22:14:26 GMT
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" <greg.dove@gmail.com> 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 <harbs.lists@gmail.com> wrote:
    
    > I expect the same.
    >
    > Harbs
    >
    > > On Jun 20, 2018, at 7:01 PM, Alex Harui <aharui@adobe.com.INVALID>
    > 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" <harbs.lists@gmail.com <mailto:
    > harbs.lists@gmail.com>> 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 <harbs.lists@gmail.com> wrote:
    > >>
    > >> DataView works in IE10+. The problem with DataView as that it’s slow.
    > >>
    > >>> On Jun 19, 2018, at 9:24 PM, Carlos Rovira <carlosrovira@apache.org>
    > 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 <aharui@adobe.com.invalid>:
    > >>>
    > >>>> Isn't ByteArray mapped to UInt8Array?
    > >>>>
    > >>>> On 6/19/18, 10:07 AM, "Harbs" <harbs.lists@gmail.com> 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
    > >
    >
    

Mime
View raw message