[Melbourne-pm] Timer::HiRes and alarms? (Was: AI Contest)
toby.corkindale at strategicdata.com.au
Wed Nov 10 21:17:30 PST 2010
On 11/11/10 15:56, Kim Hawtin wrote:
> Toby Corkindale wrote:
>> Did you ever establish what was going on here?
>> Also, I was just wondering - have you actually been having trouble
>> doing enough processing inside 1000 ms?
>> There was a point when I was exceeding it, but I was doing a lot of
>> work over and over; It was helpful to create some data structures to
>> hold everything at the start of each that I could just reference later.
>> Also, note that some data won't change at all over the course of the
>> game - the location, growth rates, and distances between planets.
>> I note that the default starter packages are not terribly optimised
>> either. For instance, whenever you request a planet by ID, it finds it
>> by iterating over the whole lot of planets, and checking to see if the
>> ID matches. >.<
>> A quick optimisation would be to use List::Util's "first", and a
>> better optimisation would be to store the planets in a damn hash table.
>> (List::Util is in core Perl 5.8.8 isn't it?)
>> I recommend sticking the fleets into a hash table based on destination
>> while you're at it..
> I was getting restless about frequently timing out. Used NYTProfile. Did
> away with all the hashes and implemented them in arrays. Used constants
> for indexes instead of hash keys. Went from 980ms to typically 270ms per
> turn. Now it only times out when theres more than 100 or so of my fleets
> on the move and that seems to be the parsing code ...
Hmm, interesting to hear.
So, the array methods are quicker than hashes for small sets?
You're probably not on the base starter package any more; but if so,
I've made a few more improvements to it which are on my Git repo.
The original author wasn't that interested in accepting my pull
requests, oh well.. I'm far outranking him on the scoreboard anyway :)
More information about the Melbourne-pm