Disclaimer: I am very out of touch with what's actually going on on
perl6-internals at the moment. (And even more out of touch with the source
code)
On Tue, Sep 24, 2002 at 04:56:25AM +, Leopold Toetsch wrote:
+return list-chunk_list[idx / INTLIST_CHUNK_SIZE];
On Tue, Sep 24, 2002 at
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke (via RT) wrote:
What happens if you presize the PerlArray to its final size
Then it is of course faster, but this is not a real world proposal IMHO,
The real-world version would increase the array's allocation by some fixed
Sean O'Rourke wrote:
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke (via RT) wrote:
The real-world version would increase the array's allocation by some fixed
multiple, e.g. double its size, which would still improve things from O(n)
to O(log n) reallocations. I suspect that
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke wrote:
If we expect these (especially shift) to be as frequent as push/pop, and
we want fast indexing as well, then maybe something like the SGI STL
implementation of a dequeue (dequeueue?) would be best: keep an array of
Sean O'Rourke wrote:
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
Sean O'Rourke wrote:
Exactly this is, what my recent patch actually did: list-chunk_list
holds pointers to chunks, an index lookup is one div more expensive
then in array.
It's not in #17549. Is it in an earlier patch?
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17549]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17549
Attached patch
- corrects a bug in int_list_assign 1)
- makes direct access fly
On Tue, 24 Sep 2002, Leopold Toetsch wrote:
intlist_3.pbc is with 1) already 10 times faster then the same test with
PerlArray (ok, that's not fair, .PerlArray has to new_pmc, which
accounts for ~40% difference).
What happens if you presize the PerlArray to its final size before the
loop?
Sean O'Rourke (via RT) wrote:
What happens if you presize the PerlArray to its final size
Then it is of course faster, but this is not a real world proposal IMHO,
you don't know in advance the usage pattern, so you can't do this. Of
course, the memory management of array/PerlArray could be