Re^2: Experimental features: autoderef vs postfix deref

Interesting, but probably not very significant.

A more interesting figure, that is probably impossible to measure, is what performance affect has this 'feature' had upon code that doesn't use it?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

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.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Comment on Re^2: Experimental features: autoderef vs postfix deref

Replies are listed 'Best First'.
Re^3: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 20:59 UTC
I thought that if you don't request the code, it isn't loaded. Can you explain what you mean? Would it be that even though the feature isn't `use`'d, it's still intertwined enough to have effects?	[reply] [d/l]
Re^4: Experimental features: autoderef vs postfix deref by BrowserUk (Patriarch) on Jul 13, 2015 at 21:37 UTC
Would it be that even though the feature isn't use'd, it's still intertwined enough to have effects? It's that I suggested it would be good to measure. Many perl features exact a cost even for code that doesn't use them. Eg. Threads: I recall reading somewhere that building with threads cost something like 7% for code that made no use of them. Unicode: The presence of the code to deal with unicode, means at the very least a lot of extra boolean checks in code paths for code that doesn't use it. Tie: The ability to tie variables means passing through checks for its presence for almost every variable access. Many other kinds of magic impose similar complexities on code that doesn't use it; just to determine that it isn't used. Individually, none of them are hugely detrimental, but combine them all together and the affects on every opcode that has to go through is-it-unicode, is-it-tied, is-it-lvalue, is-it-shared, is-it-someother-magic, add up. Whether this has any such consequences was the question. shmem may be right that this is purely a syntactic sugar thing; recognised entirely at compile time; that compiles to identical code to the normal deref; and thus has no runtime consequences at all. But your numbers above seem to indicate there may be more to it than that. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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. I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!	[reply]
Re^5: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 21:53 UTC
Thanks BrowserUK, I plan to do much more testing solely so I can see for myself, but the comments on my post here have inspired me to run much more rigorous tests similar to this on platforms dedicated to only that, just to see.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re^5: Experimental features: autoderef vs postfix deref by stevieb (Canon) on Jul 13, 2015 at 22:12 UTC
One more thing... This is a nit and I'm on my phone so I'll cite when I get home, but my understanding of the original Larry idealism of Perl is that 'important bits be to the left' (single quoted as it might not be verbatim). If that's the case, `postderef` goes against that principle. For me, it's whatever works so I don't care, but it is what it is. I think that's what I've read... I spent a lot of time over the weekend researching Perl.	[reply] [d/l]