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