Re^3: Why not perl have raw/native type

in reply to Re^2: Why not perl have raw/native type
in thread Why not perl have raw/native type

I was comparing the proposition to what happens actually in the cheapest of scenarios. So 3. is skipped, and 4. amounts to deallocate the PV. Yes, there are definitely more steps involved, and maybe some are also necessary for a RAW type.

But that's not the point. A RAW type instead of a SV(PV) would also undergo a lot of the steps the SV(PV) undergoes, even if the RAW had an inmutable type. I'm just saying that (re)assigning a string to a variable already containing just a string (i.e. only the PV slot allocated, no magic attached) is comparably cheap compared to all the "whatnot" the perl intepreter does. Is this incorrect? Then the OP makes a valid point.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Comment on Re^3: Why not perl have raw/native type

Replies are listed 'Best First'.
Re^4: Why not perl have raw/native type by ikegami (Patriarch) on Jan 11, 2020 at 06:04 UTC
None of those steps are skipped. The check needs to be performed if nothing else. I'm just saying that (re)assigning a string to a variable already containing just a string (i.e. only the PV slot allocated, no magic attached) is comparably cheap compared to all the "whatnot" the perl intepreter does. Is this incorrect? hmmm. The long list of checks I mentioned and similar ones are constantly being made. It's is quite a drain. Is it cheap compared to the rest that Perl does? If you mean the guts of operations like doing a regex match or making a system call? sure. But compared to overheads in Perl? not really. (The things you identified basically happen at compile-time, except for what amounts to a C struct lookup. They're definitely not drains!) Then the OP makes a valid point. They do. You could get great speed boosts if you could leave out a lot of checks.	[reply]

Replies are listed 'Best First'.

Re^4: Why not perl have raw/native type
by ikegami (Patriarch) on Jan 11, 2020 at 06:04 UTC

None of those steps are skipped. The check needs to be performed if nothing else.

I'm just saying that (re)assigning a string to a variable already containing just a string (i.e. only the PV slot allocated, no magic attached) is comparably cheap compared to all the "whatnot" the perl intepreter does. Is this incorrect?

hmmm. The long list of checks I mentioned and similar ones are constantly being made. It's is quite a drain.

Is it cheap compared to the rest that Perl does? If you mean the guts of operations like doing a regex match or making a system call? sure. But compared to overheads in Perl? not really. (The things you identified basically happen at compile-time, except for what amounts to a C struct lookup. They're definitely not drains!)

Then the OP makes a valid point.

They do. You could get great speed boosts if you could leave out a lot of checks.

[reply]

In Section Seekers of Perl Wisdom