Front page | perl.perl5.porters |
Postings from March 2017
bulk88 wrote:
> Dave Mitchell wrote:
>> TD;DR: I tried storing short strings directly in the SV head: a bit
>> faster,
>> but probably not practical. A variant might be practical.
>>
>> I've just pushed the branch davem/shpv_poc which contains some
>> proof-of-concept code for adding a new SV type, SVt_SHPV, which uses the
>> sv_any and sv_u fields of an SV head as a buffer to hold short strings
>> (<=14 chars on 64-bit builds), eliminating the need for an SV body and
>> malloced PVX buffer.
Another thing, your branch changes
------------------------
@@ -160,7 +162,7 @@ typedef enum {
* The bits that match 0xf0 are CURRENTLY UNUSED, except that 0xFF means a
* freed SV. The bits above that are for flags, like SVf_IOK */
-#define SVt_MASK 0xf /* smallest bitmask that covers all types */
+#define SVt_MASK 0x1f /* smallest bitmask that covers all types */
#ifndef PERL_CORE
/* Fast Boyer Moore tables are now stored in magic attached to PVMGs */
------------------------
I've always thought to extend the current arena SV body type allocator,
to common perl fixed len non-SV body structs, like GP struct. So any SV
body type above 15 is not an SV body but some other common struct and a
"if(type > 15)" or "if(type & 0xF0)" means not a SV body fixed len
struct. You took 1 more bit and added a 16th SV type. I mean you can
still implement non-body types in the arenas but now "if(type > 31)" or
"if(type & 0xe0)" and 15 permutations were lost but IDK what their
meaning would be. Can any of the existing SV types be eliminated or
aliased? I once made a branch that eliminated SVt_NULL and #define-ed it
to SVt_IV (both are bodyless, only difference is sv_any points to svu in
a SVt_IV while sv_any is NULL on a SVt_NULL, why not always keep a new
undef SV as an IV type unless otherwise upgraded, its just one CPU
subtraction op and 1 write op at SV head alloc time).
Thread Previous
|
Thread Next