[Melbourne-pm] Timer::HiRes and alarms?

[Daniel Pittman]

Toby Corkindale <toby.corkindale at strategicdata.com.au> writes:
> 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?

They should be faster than a hash for *any* set, because they are a constant
time access with zero computation, rather than a just-above-constant time
access with some computation.

Using a constant method like 'use constant' means that you can even have
symbolic names for the slot access without any greater cost; it will fold that
into the generated opcodes as this shows:

    perl -MO=Concise -e \
       'use constant FOO => 2; my @bar = (1,2,3); print $bar[FOO];'

I am surprised it made such a difference, but generally speaking that is one
of the nice optimizations you can make if you are building an object system.

This is one of the reasons I occasionally look at inside-out objects[1] or
array-backed class storage.  Generally the performance gain isn't so
impressive, though, and there is more risk of complication in a non-standard
object storage model. :)

        Daniel

Footnotes: 
[1]  Easy to use a numeric ID and a static array, although potentially costly
     when you handle finding the first free ID on create, and potentially
     painful to efficiently generate the right set of arrays if you want
     optimized accessors in the face of mutable objects.

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons