Also nobody knows "stashes" are HVs or PP packages/classes are implimented with HV*s.

Er, I kinda thought quite a few people knew this? Especially if they are fans of monkeypatching?

So if the STRLEN can be CC constant folded, and fits in a U8, store the length in the flags arg. Saves on CPU ops in all the callers to push 2 args, vs 3. Public API gv_stashpvs(str, create)'s create arg [flags in reality] can't be optimized away or removed, so combine the 2 CC time constant args, so they fold/optimize into 1 cpu op.

Does this benchmark as actually running any faster? What with CPU pipelines and execution tricks being what they are nowadays. Please could you give us some comparative numbers?

I'll try to look some more over the weekend, but no promises. Trying to learn enough about how stashes work and what gv.c does to meaningfully provide comments. :/

Also nobody knows "stashes" are HVs or PP packages/classes are implimented with HV*s.

Er, I kinda thought quite a few people knew this? Especially if they are fans of monkeypatching?

https://www.perlmonks.org/?node_id=331262

PP grammar GVs/stash's behavior is so irratic/braindamaged/bespoke that it couldn't possibly be implemented with HVs. Why can't I tie @isa or a package?

Lets write some broken code and see what happens, packages def dont behave like hashes.

C:\sources\version.pm>perl -w -e"use Devel::Peek; use ExtUtils::MakeMaker; %{*Ex
tUtils::} = (1,2); print sort keys %{*ExtUtils::}; Dump(%{*ExtUtils::}, 10);ExtU
tils::MakeMaker::WriteMakefile();

"While trying to resolve method call MM->new() can not locate package "ExtUtils::
MM" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils::MM"?)
 at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
MM_Win32" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils:
:MM_Win32"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
MM_Any" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils::M
M_Any"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
MM_Unix" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils::
MM_Unix"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
Liblist" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils::
Liblist"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
Liblist::Kid" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUt
ils::Liblist::Kid"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
While trying to resolve method call MM->new() can not locate package "ExtUtils::
MakeMaker" yet it is mentioned in @MM::ISA (perhaps you forgot to load "ExtUtils
::MakeMaker"?) at C:/pb64/lib/ExtUtils/MakeMaker.pm line 78.
Can't locate object method "new" via package "MM" at C:/pb64/lib/ExtUtils/MakeMa
ker.pm line 78.
1
C:\sources\version.pm>perl -w -e"use Devel::Peek; use ExtUtils::MakeMaker; %{*ExtUtils::} = (1,2); print sort keys %{*ExtUtils::}; Dump(%{*ExtUtils::}, 10);ExtUtils::MakeMaker::WriteMakefile();
"`

So if the STRLEN can be CC constant folded, and fits in a U8, store the length in the flags arg. Saves on CPU ops in all the callers to push 2 args, vs 3. Public API gv_stashpvs(str, create)'s create arg [flags in reality] can't be optimized away or removed, so combine the 2 CC time constant args, so they fold/optimize into 1 cpu op.

Does this benchmark as actually running any faster? What with CPU pipelines and execution tricks being what they are nowadays. Please could you give us some comparative numbers?

I can create artificial benchmarks to prove my code strategy or pattern, whatever my strategy is at that moment, is better than whatever blead was doing before, but the benchmarks synthetic and artificial. use Benchmark/cmp_these() style artificial.

A benchmark attempt using https://pubs.opengroup.org/onlinepubs/9699919799/functions/times.html or analogs like it on WinOS/AnyOS, on any production perl process, executing any kind of production PP code [p5p/.git C code] or production XSUB C code, just doesn't work from my experience. Intel's x86/x64 PMC hit count registers, which are the backend of https://perfwiki.github.io/main/tutorial/#counting-with-perf-stat are probably (no experience) equally useless as a micro benchmark if it involves libperl.so/.dll or perl.h.

times() is wall time, and takes 10s of milliseconds, or 100s of ms, before its resolution and results become a repeatable pattern for perl VM. Sometimes my mostly perl interp benchmarks and rarely non-perl aware C/C++ apps I work on, it will takes minutes, at 100% CPU on 1 core, before Win32's kernel's times() or micro_gettimeofday() start to become a pattern and prove something, C src code wise.

The electronic problem is, after a through reading of https://www.agner.org/optimize/ or skip to the end and just read https://en.wikipedia.org/wiki/Instruction-level_parallelism Modern CPUs have too many cores or hyperthread cores, and the Perl VM can only (sanely) saturate to 100% exactly 1 fake HW CPU or 1 real HW CPU on the box. ALL Intel CPUs have atleast 2 ALUs, Probably 3-4 nowadays. Each ALU does your pointer integer bitwise and HS algebra math, all if/else tests, and conditional jump, There are atleast 2, probably 4 of them randomly biting of incoming machine code. If there is nothing else to do, all 6 ALUs on 1 core, will speculative execute all your if/else branches 2 layers deep, in 1 tick, all permutations, and cold, take EQUAL wall time no mather conditional branch did or didn't execute in C code. This isn't benchmarkable by wall time or system times(). It can only be measure in artificial PMC, and you will prove its faster with one of the PMC report number but RDTSC says they are the same time, or total noise from RDTSC, like every run for loop, at 100,000 or 500000 iteractions, comes out different,
else E
If(A) |--> if(C) ^-> D
|/
elseif(B) |/--> F
else G

My CoreI SandyBrige is too smart and detects my 10K iter for() loop bench marks in my WinPerl, and usually optimizes/const folds away any C function it wants. I've had problems, where this proper/correct code/production code, which is nonsensical code, is calling WinPerl;s pretty heavy Newx. was faster !!!!! than my hooked faked NewX timpl, that just had 4 hard coded fixed length PV bufs to hand out and return. The FULL BLOWN threaded WiPerl+MS CRT+K32+NTDLL MALLOC() code path, was faster or equal than my tiny almost-NOOP vtable func, after 15 minutes of 100% CPU. My 4 core Core i5 Sandy Bridge FOLDED AWAY all of malloc. Basically all the machine code, perl+windows, fit into the CPUs L1 16KB instruction cache, and got recompiled and const folded, to nothing, which was actually true.

size_t cnt = 0;
size_t ptr =my_perl;
char * p = NULL;
for(i=0;i< 1000000; i++) {
   char * newp;
   STRLEN len =  (ptr = ptr+1) & 0xFF;
   Newx(newp, len, char);
  if(p)
    Safefree(p);
   p = newp;
  ptr = p;
}

Too much branch prediction, too much silicon, throw in a -8 to +8 avg "heat score " branch predictor trace bitfield on every condition jump op, and an instruction stream that was long ago, 100% "recompiled to intel internal "uop" language", and a for() loop that isn't getting external "input" from the outside word (DDR pins/global must cache flush announcements from other CPU cores), it just constant folded away. My WinXP Core 2 Duo Perl XS dev box, didn't do stuff this fancy, but setting to 600 mhz/6x clock multipler was need for me create sane benchmarks with libperl, no matter if it was NYTProf or WinKernel's times() or Intel PMC/RDTSC nanosecond resolution counters.

In reality, in my experience ALIGNMENT by GCC/Clang of each branchless machine code chunk, I think its called a basic block, or in C lang its called block/branch/statement/subexpression. Alignment and padding of the interp's x86/x64 machine code, to units of 16/32 bytes, and noop instruction filling until next 16/32 boundary, is the LARGEST reason for ultra narrow and artificial benchmark swings of times(). Its not instruction count cpu op by cpu op, its not memory deref counts of structs. Its the layout and alignment in address space and layout/alignment, in the disk binary, by the C compiler, or C linker, of each set or array of branchless instructions, until the next cond branch instructions. These -O2 -O3 alignment games produces huge results for video/audio decoders and encoders that spend milliseconds!!! inside 1 huge C function, but are N/A to P5 and its design optree design, and most Perl_pp_*() funcs are medium weight things, that somewhere call 1-3 more C functions to get their job done. Those extra C functions break up/invalidate that GCC/Clang hyper-align-for-speed tactic.

Light weight Perl_pp_*() funcs, like Perl_pp_null Perl_pp_introcv Perl_pp_once Perl_pp_pushmark Perl_pp_is_weak Perl_pp_gv Perl_pp_padcv Perl_pp_const contribute nothing to wall clock latency even with sky high runtime execution counts IMO.

Its the other Perl_pp_*() functions that cause all speed problems. Those which must call into P5's middleware code, that lives in gv.c, sv.c and hv.c. And that middleware in blead has alot, ALOT, of algorithm inefficiency flaws, of the O(n) or O(n^2) style, which drown out C-in-assembly tweaks.

For example, this is from a paused miniperl.exe's malloc() pool, OMGWTPerl!!!!

I'll try to look some more over the weekend, but no promises. Trying to learn enough about how stashes work and what gv.c does to meaningfully provide comments. :/

Just single step any random blead miniperl or fullperl process that executes during a self make all. Set some breakpoints in gv.c, and hold F11 (MSVS IDE) for a while. If you dont know where to set your first BP, my favorite one to demonstrate what is wrong is Perl_newXS_len_flag() at