When I ran vr's original code on Ubuntu, with both threaded and unthreaded builds of perl-5.26, the timings didn't alter significantly.
But I didn't have an unthreaded Windows build to test with.
I have now built one (perl-5.26) only to discover that one can't install a usable Inline::C because Win32-IPC (more specifically, Win32-Mutex) doesn't compile.
One can successfully force install Inline::C, but it's unusable.
Unfortunately, Win32::IPC builds using Module::Build - and I simply cannot stomach any troubleshooting that involves Module::Build.
It would have been nice to verify whether an unthreaded build on Windows does access Inline::C functions faster.
Maybe someone else ....
One can successfully force install Inline::C, but it's unusable
While that's so for the latest version of Inline::C, it's quite simple to install older versions of Inline::C on the unthreaded Windows (as they don't carry the Win32::IPC baggage that comes with recent versions).
So, I installed Inline-0.55, though I perhaps didn't need to go that far back.
Here are the results using vr's original one-liners:
On threaded perl-5.26.0 with current Inline::C version 0.78:
It therefore appears that reverting to an older version of Inline::C makes very little difference, whereas using Inline::C on an unthreaded Windows perl-5.26.0 markedly improves performance when calling Inline::C subs from perl.
Unfortunately, it also seems that calling perl subs on an unthreaded Windows perl-5.26.0 takes about 30% longer (as compared to the time it takes on the threaded perl).
Of course, things might be quite different on the soon-to-be-released perl-5.28.0.
And things might also be quite different on 32-bit builds of perl.
ikegami, yes, both Perls are threaded 5.26 (it's in OP).
syphilis, thanks a lot for your research. I still hope, C code can be compiled into "faster version" i.e. with speed on par with unthreaded or Linux Perls. Core XS modules don't run 2 times slower on Windows.
Here's a little experiment. The hv_store (Hash::Util) is documented as
(BTW, as an aside, some funny and interesting things can be done with aliases stored as aggregate elements, it seems references overshadowed this feature which has been there for free for decades, no new experimental "refaliasing" required for that (it's not surprising since they are "aggregate elements", not regular variables). But you know all that.)
So, a couple weeks ago I accidentally found Hash::Util::hv_store is almost exactly 2 times faster than Array::RefElem::hv_store. I thought it strange but didn't investigate it then. Now:
>perl -MTime::HiRes=time -MHash::Util=hv_store -wE"%h=();$t=time;hv_st
+ore(%h,'foo',42) for 1..1e8;say time-$t"
>perl -MTime::HiRes=time -MArray::RefElem=hv_store -wE"%h=();$t=time;h
+v_store(%h,'foo',42) for 1..1e8;say time-$t"
$ perl -MTime::HiRes=time -MHash::Util=hv_store -wE'%h=();$t=time;hv_s
+tore(%h,"foo",42) for 1..1e8;say time-$t'
$ perl -MTime::HiRes=time -MArray::RefElem=hv_store -wE'%h=();$t=time;
+hv_store(%h,"foo",42) for 1..1e8;say time-$t'