[QUESTION] PMC Pre-allocation
Karl Forner
Is there a way to specify a minimum allocation size for PMCs like strings or
arrays ?
Something like in perl : %h = 1000 ?
It could boost execution times when you have a good idea of the space you
need.
For example, I'd like to do:
#ensure that the array has enough allocated storage for 1000000 elements
without need for allocationg memory
new P0, .Array, 1000000
and then push 1,000,000 elements.
N.B: it is not the same as
new P0, .Array
P0 = 1000000
Thx
Karl
Leopold Toetsch
This isssue was already discussed a few times. Last time was likely, when I
introduced the elements opcode, which helps at least to fix the 'get' side of
the problem.
It originated in a perl5-ism in the first array implementations, following the
perl-way:
$elems = scalar @array;
which was directly translated to:
set I0, P0
This works at least for "small" arrays.
The problem is now of course, that we are forcing perl syntax elements on all
HLLs having arrays. Now we have additionally:
elements I0, P0
with it's own vtable. The problem is of course that the former construct is
used heavily.
There's no such thing for setting the size or/and the allocation. And worse,
arrays are implementing:
set P0, I0 # pre-size or allocate and fill and set element count?
... in an inconsistent way.
IMHO the only way to get rid of this historical confusion is:
- disable the set opcode for arrays by throwing an exception in the vtable
- use elements for getting .elems only
- implement 2 new opcodes
elements P0, I0 # fill with default value, set element count to I0
presize P0, I0 # allocate storage, elem count is unchanged
- implement an introspection method to get various info like allocated size or
storage needed
> Thx
> Karl
leo
Karl Forner
> IMHO the only way to get rid of this historical confusion is:
>
> - disable the set opcode for arrays by throwing an exception in the vtable
> - use elements for getting .elems only
> - implement 2 new opcodes
> elements P0, I0 # fill with default value, set element count to I0
> presize P0, I0 # allocate storage, elem count is unchanged
> - implement an introspection method to get various info like allocated
> size or
> storage needed
I totally agree.
Karl
Allison Randal
Leopold Toetsch wrote:
>
> It originated in a perl5-ism in the first array implementations, following the
> perl-way:
>
> $elems = scalar @array;
>
> which was directly translated to:
>
> set I0, P0
>
> This works at least for "small" arrays.
>
> The problem is now of course, that we are forcing perl syntax elements on all
> HLLs having arrays. Now we have additionally:
>
> elements I0, P0
>
> with it's own vtable. The problem is of course that the former construct is
> used heavily.
What does 'elements' do if P0 is a scalar? Return '1'? Hmmm... nope. For
Strings it returns the number of characters (or codepoints?), and for
Integers it complains the method isn't implemented. For native strings
it complains the opcode doesn't exist. Seems like a feature that could
use some edge-case thinking.
> There's no such thing for setting the size or/and the allocation. And worse,
> arrays are implementing:
>
> set P0, I0 # pre-size or allocate and fill and set element count?
>
> ... in an inconsistent way.
Probably because "set array size" (in the documentation for arrays) is
ambiguous.
> IMHO the only way to get rid of this historical confusion is:
>
> - disable the set opcode for arrays by throwing an exception in the vtable
If we really have no other use for 'set'-ing an integer on an array,
setting the number of elements is the most sensible meaning.
> - use elements for getting .elems only
If we have no other use for getting an integer value from the array, it
might as well return the number of elements in the array. I'd say this
is one of those bits of functionality that is both a vtable entry and a
method in the namespace.
> - implement 2 new opcodes
> elements P0, I0 # fill with default value, set element count to I0
> presize P0, I0 # allocate storage, elem count is unchanged
Using 'elements' for both getting and setting is too confusing. And I'd
lean away from adding more opcodes that are only relevant to a small set
of data types.
More appealing is a method for allocating memory without changing the
number of elements. It's the less common case, and so doesn't need the
shortest shortcut. Or, passing the array a Hash init argument in 'new',
with a key something like 'alloc' or 'mem'. That would save the hit of
allocating the array and immediately reallocating it.
> - implement an introspection method to get various info like allocated size or
> storage needed
Yes. Several introspection methods, probably.
Allison