Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by ikegami (Pope)
on Jan 10, 2020 at 04:15 UTC ( #11111274=note: print w/replies, xml ) Need Help??


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

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

  1. Call GET magic on the scalar being assigned if any.
  2. Check what the scalar being assigned contains (which happens to be a string).
  3. Upgrade the scalar to which we are assigning to one that can contain a string if needed.
  4. 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.)
  5. 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.

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'

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11111274]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (5)
As of 2020-11-30 21:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?