in reply to Re^3: Some thoughts on Moose Attributes
in thread Some thoughts on Moose Attributes

As an implementor, I answer wholeheartedly yes. The naïve implementation of an object system in Perl 5 (stolen almost whole cloth from Python) actively presents many simple and nearly all clever optimizations. Decoupling representation from behavior at the class or metaclass layer would allow gradual and progressive optimizations for memory usage or compatibility with C data structures or persistence mechanisms or JIT with much less work (and much, much less cleverness) than doing so with the simple hash-based lookup mechanism currently in place in Perl 5.

Sorry, but that is tantamount to the single most dishonest thing I've ever seen expressed on PerlMonks!

I usually refrain from trying to predict the future, but: It ain't never gonna happen. Any of it.

You don't need to implement the whole solution to prove me wrong. Just a single demonstration of method call being faster than a hash lookup in Perl 5.

Implement the extension/optimisation in any language you like, but I bet you cannot return a previously set value, to perl via method call, quicker than it can be retrived from a hash.

Note: I'd really like you to prove me wrong. Because such an optimisation could be very beneficial in almost every area of perl.

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.
  • Comment on Re^4: Some thoughts on Moose Attributes

Replies are listed 'Best First'.
Re^5: Some thoughts on Moose Attributes
by chromatic (Archbishop) on May 02, 2011 at 02:44 UTC
    It ain't never gonna happen.

    I agree it's unlikely.

    I bet you cannot return a previously set value, to perl via method call, quicker than it can be retrived from a hash.

    Who said anything about a method call? What I have in mind is something as fast as a lexical lookup, which as an indexed lookup (and, of course, modulo pad depth and optimization) is (often) quicker than a hash lookup.

    With that said, optimizing method lookups where possible is also useful, and perhaps necessary in this case. I believe this is most feasible with a system of gradual optimizations. It's also highly unlikely with the Perl 5 source code as it is now.

[reply]
      I agree it's unlikely.

      'nuff said.

      Who said anything about a method call?

      In the context of "Decoupling representation from behavior at the class or metaclass layer " I don't see how a faster direct access mechanism achieves that "decoupling". But I'll accept that I may have misunderstood you.

      What I have in mind is something as fast as a lexical lookup, which as an indexed lookup (and, of course, modulo pad depth and optimization) is (often) quicker than a hash lookup.

      I once went quite a long way in developing a closure-based object mechanism. By instantiating a full set of closures for every object instance--kind of JS prototypical I think?--you do get direct lexical access to instance variables. With the obvious downsides.

      Maybe a new storage specifier somewhat like, but essentially opposite to state (perhaps 'volatile' or less C-like, 'instance'), could be added to perl 5 that would essentially create a new stash (duplicated from the package stash) could come into being for each new instance? Just a random thought that crossed my conciousness.

      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.
[reply]

        A new storage specifier might work, but the best way I've seen to implement this is to go all of the way to a full-fledged metaobject system. At the point where you can separate method dispatch from the normal global lookup system plus inheritance fallback, you allow for the possibility of type specialization and optimization, perhaps through a finalization system or (my preference) a tracing optimizer at runtime.

        From there you can get to autounboxing-style optimizations. (Remember that research into Self and Smalltalk and Strongtalk shows that 90% of all dynamic language programs are statically analyzable.)

[reply]
[d/l]

In Section Seekers of Perl Wisdom