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

Assigning a string is actually quite complex when dealing with scalars.

Call GET magic on the scalar being assigned if any.
Check what the scalar being assigned contains (which happens to be a string).
Upgrade the scalar to which we are assigning to one that can contain a string if needed.
Clear whatever value the scalar to which we are assigning contains. (This can require reducing reference counts (which can require calling destructors, etc), reducing COW counts, resetting OOB vars, etc.)
Finally, we can start the copy. That can happen one of three ways. Hopefully, it's just a question of copying a pointer and incrementing the COW reference count.

(I definitely skipped some steps. I got tired of typing.)

Walking the optree, on the other hand, is simply following a linked list. (Effectively, op = op->next.) This is way simpler than assigning a string.

Comment on Re^2: Why not perl have raw/native type Download Code

Replies are listed 'Best First'.
Re^3: Why not perl have raw/native type by shmem (Chancellor) on Jan 10, 2020 at 13:03 UTC
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'	[reply]
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]