Re^5: Autovivifying XS routine

... overload stuff is called from the code that interprets the de-referencing opcodes ... If it's slow, that's probably not because it has to determine the kind of reference needed,

Exactly. It knows what it's got to do. It only needs to chase a few pointers in magic to find the callback--and still it is notoriously slow.

A cursory peek at want.xs shows an aweful lot of logic, including several physically and logically nested loops tracing opcode trees. I won't pretend to have understood half of what I saw in there, but it looks expensive, which supports my findings from a while ago.

My point is that it might be faster, and simpler, to have gimme_a_ref() return a ref blessed into a package that overloads the dereference operators. Especially as Alter is already using (as far as I understood your other thread), two levels of inside-out-style dereferencing which is already slow.

Additionally, what happens if someone assigns the return from gimme_a_ref() to a scalar, and then attempts to dereference it later? You'll have no applicable 'current context' at the time of the call from which to determine what use will be made of what you return.

Admittedly that can be addressed through documentation, but you'll be denying flexibility. You'll also create the situation of requiring the additional overhead of determining the calling context for every use.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^5: Autovivifying XS routine Select or Download Code

Replies are listed 'Best First'.
Re^6: Autovivifying XS routine by Anno (Deacon) on Jun 01, 2007 at 18:40 UTC
...peek at want.xs shows an aweful lot of logic Right. I disentangled the part that I'd need and ended up with (almost) half the code from Want.xs. Speed issues aside, that's not reasonable. what happens if someone assigns the return from gimme_a_ref() to a scalar, and then attempts to dereference it later? That would be no different from other autovivifying situations. You can say `my $x; $x->{hihi}->{haha} = 'hoho';` [download] but you can't keep `$x->{hihi}` for later, as in `my $x; my $y = $x->{hihi}; $y->{haha} = 'hoho';` [download] So I'm not worried much about that effect, but the autovivifying option is out for the reason above. Alter is already using ..., two levels of inside-out-style dereferencing It's not quite as bad. `Alter::ego` is one hash access slower than the inside-out equivalent `Hash::Util::refaddr`. That's the difference that matters afaik, otherwise they do about the same amount of almost nothing. Anno	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: Autovivifying XS routine
by Anno (Deacon) on Jun 01, 2007 at 18:40 UTC

peek at want.xs shows an aweful lot of logic

Right. I disentangled the part that I'd need and ended up with (almost) half the code from Want.xs. Speed issues aside, that's not reasonable.

what happens if someone assigns the return from gimme_a_ref() to a scalar, and then attempts to dereference it later?

That would be no different from other autovivifying situations. You can say

my $x;
$x->{hihi}->{haha} = 'hoho';
[download]

$x->{hihi}

my $x;
my $y = $x->{hihi};
$y->{haha} = 'hoho';
[download]

Alter is already using ..., two levels of inside-out-style dereferencing

It's not quite as bad. Alter::ego is one hash access slower than the inside-out equivalent Hash::Util::refaddr. That's the difference that matters afaik, otherwise they do about the same amount of almost nothing.

Anno

[reply]
[d/l]
[select]