Hi Bilbosax: Just my 2 cents on some things to consider: according to your code, it's something like
"If 10 conditions are met, do the math" Instead of writing it as a series of nested ifs (a real mess for your CPU branch prediction module), try this: dothemath=(condition1) && (condition2) && .... && (condition10) if (dothemath) do_the_math() Since boolean expressions are evaluated left to right, you are not adding any additional complexity, your loop is now turned to almost linear (just one branch, not 10), flash compiler is much happier, your CPU branch predictor can now do its job (instead of committing suicide), and if you even manage to previously sort your data so dothemath is always true for the first n records and false for the rest (or at least part of them, sorting by condition1 for instance), you could always get full pipeline coverage, getting a result every clock tick (and a gigahertz clock is a very fast clock :) Besides, instead of running it 38k*38k times, could you also precalculate some part (or all) of your conditions linearly (38k), and then do the nested loop? Even better, couldn't you just store partial results in a 38k long dictionary, and then just do a linear loop referencing the result on that dictionary? Even better, couldn't you just make your SQL server handle part of the job on the query itself, and return a reduced result set based on those conditions? It has most of the data (without needing to cast strings to integers) at hand, and it reaaaaally knows how to iterate through 38k records really fast (it's the only thing it does really well :). In general, could you just give us more data on the calculations (change constants, operations, anything you want except variable referencing) so we can help you better? Me (and many others) do believe it can be further optimized to seconds, but we do "need to know" :) Hope it helps! :) P.S. The other way round: would it hurt if you do the math linearly first for every record (just 38k), and then just select the ones that meet all 10 conditions (38kx38k IFs)? P.P.S. Of course, you have turned OFF automatic updates on all your involved bindables before the loop, and enabled them afterwards, right? :) On Wed, Aug 3, 2016 at 4:04 AM, bilbosax <waspenc...@comcast.net> wrote: > What about changing datatypes, does this eat up a lot of time? My database > has some values that are typed as string but are actually numbers. When I > download them from the database, I assume that they are entered into the > arraycollection as strings. In my loops, I have to do math functions on > them so I force them to a number type as such: > > var a:Number = Number(myArray[1].someProp)*10; > > When doing this a large number of times in big loops, will it eat up a > significant amount of time or is type conversion pretty fast? > > > > -- > View this message in context: > http://apache-flex-users.2333346.n4.nabble.com/Workers-and-Speed-tp13098p13158.html > Sent from the Apache Flex Users mailing list archive at Nabble.com. >
