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

[Daniel Pittman]

Sam Watkins <sam at nipl.net> writes:
> On Fri, Nov 12, 2010 at 11:05:57AM +1100, Jacinta Richardson wrote:
>
>> When you create an array in Perl, Perl creates a hunk of memory for it and
>> puts the array in the middle.  If you unshift or push things onto the array
>> they bring the start or end of the array closer to the boundaries of the
>> memory Perl put aside for you.  If you get "too close" to either end, then
>> Perl allocates twice as much space for you (as it did the first time) and
>> copies your array into the middle of that.
>
> That's interesting, I didn't know it worked like that.

Almost as if the authors of Perl have the freedom to make their
implementations extremely efficient because they have a well defined API
surrounding the internals, like well architected software. :)

[...]

> I was thinking a bit about how to create a data structure that would be very
> efficient for insertions / deletions at any point, and also for random
> access.

You almost certainly want the trie-based concurrent and immutable data
structures used extensively in Clojure, among other places.

> Maybe a hybrid tree of arrays (or tree of deques), where the user could
> balance insert performance against compactness and random-access speed, and
> call a 'squeeze' or 'flatten' function to squash it into a simple array /
> deque.  This could be useful.  It sounds a bit complex, but I guess could be
> implemented fairly simply.

Relatively, yes.  They can serve as the basis for purely functional,
efficiently shared map and sequence data storage, with reasonably predictable
and controlled access times and patterns.  (Fairly flat, too, so you don't
have particularly many spikes in the worst-case time.)

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