summaryrefslogtreecommitdiff
path: root/sv_inline.h
Commit message (Collapse)AuthorAgeFilesLines
* SvGETMAGIC: evaluate its argument just onceKarl Williamson2022-06-101-0/+19
| | | | | | | This required making it into an inline function. I tried using STMT_START{ ... } STMT_END, which should work since it has a void return, but there were places where it was used in a comma operator, and those did not compile.
* Move sv.h functions from inline.h into sv_inline.h,Richard Leach2022-05-281-0/+303
| | | | | so that all functions inlined from sv.* are in one place. This was suggested by @khw.
* Perl_newSV_type_mortal - new inline function introduced and usedRichard Leach2022-03-071-8/+45
| | | | | | | | | | | | | | | There's no efficient way to create a mortal SV of any type other than SVt_NULL (via sv_newmortal). The options are either to do: * SV* sv = sv_newmortal; sv_upgrade(sv, SVt_SOMETYPE); but sv_upgrade is needlessly inefficient on new SVs. * SV* sv = sv_2mortal(newSV_type(SVt_SOMETYPE) but this will perform runtime checks to see if (sv) and if (SvIMMORTAL(sv), and for a new SV we know that those answers will always be yes and no. This commit adds a new inline function which is basically a mortalizing wrapper around the now-inlined newSV_type.
* Make newSV_type an inline functionRichard Leach2022-03-071-0/+495
When a new SV is created and upgraded to a type known at compile time, uprooting a SV head and then using the general-purpose upgrade function (sv_upgrade) is clunky. Specifically, while uprooting a SV head is lightweight (assuming there are unused SVs), sv_upgrade is too big to be inlined, contains many branches that can logically be resolved at compile time for known start & end types, and the lookup of the correct body_details struct may add CPU cycles. This commit tries to address that by making newSV_type an inline function and including only the parts of sv_upgrade needed to upgrade a SVt_NULL. When the destination type is known at compile time, a decent compiler will inline a call to newSV_type and use the type information to throw away all the irrelevant parts of the sv_upgrade logic. Because of the spread of type definitions across header files, it did not seem possible to make the necessary changed inside sv.h, and so a new header file (sv_inline.h) was created. For the inlined function to work outside of sv.c, many definitions from that file were moved to sv_inline.h. Finally, in order to also benefit from this change, existing code in sv.c that does things like this: SV* sv; new_SV(sv); sv_upgrade(sv, SVt_PV) has been modified to read something like: SV* sv = newSV_type(SVt_PV);