Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: XS module in ithreads Perl much slower in threads::join after adding SvOBJECT_off

by dave_the_m (Monsignor)
on Feb 28, 2022 at 13:41 UTC ( [id://11141705] : note . print w/replies, xml ) Need Help??


in reply to XS module in ithreads Perl much slower in threads::join after adding SvOBJECT_off

I haven't ploughed through that long thread, but here are some basics that might point you in the right direction.

When a thread is created, the whole active interpreter at that point is cloned (copied) into the new thread. When a thread ends, whatever SVs it returns (either explicitly via return, or implicitly as the last statement, or for XS, whatever SVs it pushes into the stack) are cloned back into the parent thread, by the parent calling the join() method. If the return SVs are non-trivial (e.g. have been blessed into a package), then additional stuff needs to be cloned back. For example if the object is in class X and the 'X' package doesn't exist in the parent (say 'use X' was done in the child, not the parent), then the X package and all the methods in that namespace need copying back too.

What you are seeing is probably a situation where a large 'reverse clone' is being triggered by one of the SVs being returned to the parent. One possibility related to objects is the SVphv_CLONEABLE flag, which if set on the stash the object has been blessed into, triggers reverse-cloning the stash of that object.

One possible side effect of turning off SvOBJECT() on the object is that it causes the SVphv_CLONEABLE test to be skipped (that test is only done on objects) which somehow causes the the stash associated with the (now unblessed) object to be cloned.

But that's just wild speculation at the moment.

Dave.

Replies are listed 'Best First'.
Re^2: XS module in ithreads Perl much slower in threads::join after adding SvOBJECT_off
by etj (Deacon) on Feb 28, 2022 at 20:50 UTC
    Nearly all of the thread is about other performance stuff, and was only linked here for completeness/interest; the heart of it for this purpose is as stated.

    Thank you, the above is very plausible and I have opened an issue on PDL::Parallel::threads quoting your wisdom: https://github.com/run4flat/PDL-Parallel-threads/issues/6.