A release SWF should outperform a debug SWF, so that's expected.

On 10/18/13 5:07 PM, "Mark Kessler" <kesslerconsult...@gmail.com> wrote:

>That newer link gives me faster results... lol
>
>1.71s
>1.54s
>0.903s
>
>
>
>On Fri, Oct 18, 2013 at 7:58 PM, Maurice Amsellem <
>maurice.amsel...@systar.com> wrote:
>
>> I tried already and the results are consistent.
>>
>> Here is the link:
>>
>>
>> 
>>https://dl.dropboxusercontent.com/u/12169005/ApacheFlex/TestUIDPerf_relea
>>se.swf
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Alex Harui [mailto:aha...@adobe.com]
>> Envoyé : samedi 19 octobre 2013 01:56
>> À : dev@flex.apache.org
>> Objet : Re: UID performance
>>
>> Actually, I thought of one more test that needs to be run which I don't
>> have time to do right now: Release player with release SWF.  Sometimes
>>you
>> can get very different results on the debugger players.
>>
>> Thanks,
>> -Alex
>>
>> On 10/18/13 4:53 PM, "Alex Harui" <aha...@adobe.com> wrote:
>>
>> >Yup, V3 wins on mac and windows for me.
>> >
>> >Thanks for doing it.
>> >
>> >-Alex
>> >
>> >On 10/18/13 4:45 PM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>> >wrote:
>> >
>> >>I have posted FB project with the source s + compiled SWF.
>> >>
>> >>https://dl.dropboxusercontent.com/u/12169005/ApacheFlex/TestUIDPerf.fx
>> >>p
>> >>https://dl.dropboxusercontent.com/u/12169005/ApacheFlex/TestUIDPerf.sw
>> >>f
>> >>
>> >>Algorithm 1= Original
>> >>Algorithm 2 = using Array.join() and other optimizations by JMcLean
>> >>Algo 3:  using single static byteArray (Maurice)
>> >>
>> >>These are the results I get for 100,000 iterations:
>> >>
>> >>Original: 2.74s
>> >>V2:  2.5s
>> >>V3:  1.70s
>> >>
>> >>Please can you test on your side as well...
>> >>
>> >>Maurice
>> >>
>> >>-----Message d'origine-----
>> >>De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
>> >>Envoyé : samedi 19 octobre 2013 00:56
>> >>À : dev@flex.apache.org
>> >>Objet : RE: UID performance
>> >>
>> >>I have used a static ByteArray as suggested: much better.
>> >>Thanks for the suggestion.
>> >>
>> >>
>> >>-----Message d'origine-----
>> >>De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
>> >>Envoyé : samedi 19 octobre 2013 00:49
>> >>À : dev@flex.apache.org
>> >>Objet : RE: UID performance
>> >>
>> >>Sure, I will do that.
>> >>
>> >>I will  also post the source so that you can recompile at your
>> >>convenience.
>> >>
>> >>Maurice
>> >>
>> >>
>> >>-----Message d'origine-----
>> >>De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 19 octobre
>> >>2013
>> >>00:13 À : dev@flex.apache.org Objet : Re: UID performance
>> >>
>> >>I'm a bit surprised that ByteArray.writeByte is faster but maybe
>> >>Array.join isn't that fast.  I would also like to see a test of a
>> >>single static bytearray and resetting it and/or overwriting the old
>> bytes.
>> >>
>> >>Maybe if you put a SWF with various algorithms in your people.a.o
>> >>folder folks can hit it and make sure we all get the same results and
>> >>then we'll know which algorithm to check in.
>> >>
>> >>Thanks for this idea as well.
>> >>
>> >>-Alex
>> >>
>> >>On 10/18/13 3:05 PM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>> >>wrote:
>> >>
>> >>>Any answer ?
>> >>>
>> >>>-----Message d'origine-----
>> >>>De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
>> >>>Envoyé : vendredi 18 octobre 2013 14:39 À : dev@flex.apache.org
>>Objet :
>> >>>RE: UID performance
>> >>>
>> >>>Hi,
>> >>>
>> >>>I shouldn't have mixed the two options, because it's confusing.
>> >>>
>> >>>Actually, V3 option generates uppercase, exactly as the current UUID,
>> >>>and it's 2x faster.
>> >>>So let's forget about V4...
>> >>>
>> >>>Here is the code:
>> >>>
>> >>>    private static const HEX_CHARS:String = "0123456789ABCDEF";
>> >>>    private static const DASH:int = 45;  // "-"
>> >>>
>> >>>public static function createUID():String
>> >>>    {
>> >>>        var ba:ByteArray = new ByteArray();
>> >>>        var i:int;
>> >>>        var j:int;
>> >>>
>> >>>        for (i = 0; i < 8; i++) {
>> >>>            ba.writeByte(HEX_CHARS.charCodeAt(Math.random() * 16));
>> >>>       }
>> >>>
>> >>>        for (i = 0; i < 3; i++)
>> >>>        {
>> >>>            ba.writeByte(DASH);
>> >>>            for (j = 0; j < 4; j++)
>> >>>            {
>> >>>                ba.writeByte(HEX_CHARS.charCodeAt(Math.random() *
>>16));
>> >>>            }
>> >>>        }
>> >>>
>> >>>        ba.writeByte(DASH);
>> >>>
>> >>>        var time:Number = new Date().getTime();
>> >>>
>> >>>        var timeString:String = ("0000000" +
>> >>>time.toString(16).toUpperCase()).substr(-8);
>> >>>        ba.writeUTFBytes(timeString);
>> >>>
>> >>>        for (i = 0; i < 4; i++)
>> >>>        {
>> >>>            ba.writeByte(HEX_CHARS.charCodeAt(Math.random() * 16));
>> >>>        }
>> >>>
>> >>>        return ba.toString();
>> >>>    }
>> >>>
>> >>>-----Message d'origine-----
>> >>>De : Justin Mclean [mailto:jus...@classsoftware.com] Envoyé :
>> >>>vendredi
>> >>>18 octobre 2013 14:34 À : dev@flex.apache.org Objet : Re: UID
>> >>>performance
>> >>>
>> >>>Hi,
>> >>>
>> >>>> V3: generates the random hex bytes one by one, and writes them to
>> >>>> the BA
>> >>>> V4: generates 4 or 8 random bytes in one shot, and writes them to
>> >>>> the BA  (hexa in lowercase, to avoid call toUppercase() )
>> >>>Probably best not too fiddle too much with the UID construction.
>> >>>While I can't think of any major issues it would cause there could be
>> >>>subtle issues due to seeding of random numbers and the like.
>> >>>
>> >>>> I don't know if this is acceptable (are we breaking some code if we
>> >>>>use lowercase instead of uppercase).
>> >>>
>> >>>Again can't think of any issues but probably safer if we kept it
>> >>>upper case.
>> >>>
>> >>>Go ahead and post the code it could be interesting/useful to someone.
>> >>>
>> >>>Thanks,
>> >>>Justin
>> >>
>> >
>>
>>

Reply via email to