Forgot about this :-( You are right, FF is running debugger version of FP, so that explains the difference. Thanks for the check.
BTW, thanks also for the static recycled ByteArray idea, this is an easy and efficient optimization that I could also use in my own code. Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 19 octobre 2013 02:07 À : dev@flex.apache.org Objet : Re: UID performance I assume you double-checked in flashplayerversion.com that FF is running a release player? It could be that bytearray got optimized over time as it was a key piece of gaming strategy and Alchemy. -Alex On 10/18/13 5:04 PM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: >FYI, I tried with Chrome (FP 11.9) and Firefox (FP 11.4) and the >results are quite different: > >Chrome FP 11.9: >1.29 >1.24 >0.405 > >FireFox FP 11.4: >2.16 >1.93 >1.07 > >Is the difference expected ? That is, is FP 11.9 twice as fast as FP >11.4, or is it just for these computations. > >Maurice > >-----Message d'origine----- >De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] >Envoyé : samedi 19 octobre 2013 01:59 >À : dev@flex.apache.org >Objet : RE: UID performance > >I tried already and the results are consistent. > >Here is the link: > >https://dl.dropboxusercontent.com/u/12169005/ApacheFlex/TestUIDPerf_rel >eas >e.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.f >>>x >>>p >>>https://dl.dropboxusercontent.com/u/12169005/ApacheFlex/TestUIDPerf.s >>>w >>>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 >>> >> >
