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

[Toby Corkindale]

On 11/11/10 16:46, Daniel Pittman wrote:
> Toby Corkindale<toby.corkindale at strategicdata.com.au>  writes:
>> On 11/11/10 15:56, Kim Hawtin wrote:
>>> Toby Corkindale wrote:
>>> 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.

I was confused by how it could be computation-free for a moment, then 
realised you're talking about accessing things by doing $planets[$id], 
which of course is quicker than $planets->{$id}.

I have been assuming that the IDs were more complicated and could 
potentially be ANY number, but now I re-read the spec I see that yes, 
you're only ever have a continuous list starting from 0 again each time.

I have no idea why the original starter package was using linear 
searches then! WTF?

Original code was (abbreviated code):

sub GetPlanet {
   for ($self->Planets) {
     $planet = $_ if $_->GetId == $desired_id;
   }
   return $planet;
}

Heh. I "improved" it to be at least
sub GetPlanet {
   return first { $_->PlanetId == $desired_id } $self->Planets;
}


I must make a note to fix that then!


Toby