small .h trick for faster win32 interp compiles, cl.exe in the prompt is

[bulk88]

much faster eye. PERL_CORE only, since CPAN XS assumes the built-in out the box headers/tokens/structs/linker libs selected by p5p decades ago, will never change.

[mauke]

What does "cl.exe in the prompt is much faster eye" mean?

[Leont]

If anyone later does need any of the functionality you're leaving out now, can they do that?

[tonycoz]

What does "cl.exe in the prompt is much faster eye" mean?

I assume it's faster "by eye"

If anyone later does need any of the functionality you're leaving out now, can they do that?

It only limits the APIs declared under PERL_CORE, If we (perl core) need APIs this suppressed we can remove the NO* definition this adds.

The change really needs the defines and inner pre-processor conditionals indented to make what's guarded by the conditionals obvious.

[Leont]

It only limits the APIs declared under PERL_CORE, If we (perl core) need APIs this suppressed we can remove the NO* definition this adds.

Yeah than that doesn't matter.

The change really needs the defines and inner pre-processor conditionals indented to make what's guarded by the conditionals obvious.

I agree that would make it easier to read.

[xenu]

I don't have tuits to benchmark the change, but I looked at the timings of GitHub Actions runs on a few recent blead commits.

This is the "Build" step:

Commit	msvc142	mingw64
This PR	5m 24s	5m 57s
Currently the latest commit in blead	5m 23s	5m 45s
Latest-1	5m 39s	5m 49s
Latest-2	5m 40s	6m 2s
Latest-3	5m 19s	5m 53s
Latest-4	5m 35s	5m 42s

The numbers are pretty much just noise. I'm not sure what "much faster" means, but I don't see it here.

[bulk88]

indents fixed, alpha sorted, replaced cargo culted comments, some of the macros, in my VC 2022 SDK (IDK how old it is), they exist, where MS Devs specifically say to use the macro for perf, BUT, the macro is not implemented anywhere else, and doesnt actually do anything. I have no other old or newer SDKs to check. I marked those macros as OBSOL/FUT, since either they are obsolete, or MS will randomly ship the implementation in the monthly VC/SDK rolling release cycle.

Breakage is easy to fix, and only with future unknown MSVCs, and only for core compiles. Typ win users almost never compile Perl interp with the makefile, and instead use Strawberry/prebuilt PM exe/dlls. But they do compile XS modules themselves, so this patch is core only, never cpan.

[bulk88]

I don't have tuits to benchmark the change, but I looked at the timings of GitHub Actions runs on a few recent blead commits. The numbers are pretty much just noise. I'm not sure what "much faster" means, but I don't see it here.

You are comparing an enterprise cloud server with unlimited cores and unlimited company funds in a datacenter, that is replaced and thrown out every 18 months, vs personal hobby PCs or laptops. A faster recompile of miniperl.exe or perl541.dll binaries alone, improves dev time and lowers the time needed to create a working patch, and people donate that time, unpaid, to Perl core. Saving even 2 or 3 seconds, until you get a C syntax error is worth it, added up over an hour, now thats a few minutes, then hours, and so forth.

4 out of the 5 minutes are spent on the very slow (minutes) /mktables pl script, and the building XS modules and 100 ms startup time of dozens of gmake.exe procs and 40 ms?? per 1000s of cmd.exe proc launches, and 1000s of slow launches of ExtUtils::Command.pm but thats another thread/ticket/talk.

edit: running timeit gmake -j7 CCTYPE=MSVC143 test-prep

379 seconds, 6.3 mins for me

[bulk88]

win64_build_product_proc_times.pl.txt

Attaching timing, without the patch above, in floating point seconds, of building Win64 perl, 1 core was used/not parallel. 600-1000 ms per .c seems high, and its perl specific, since fcrypt.c which is NO PERL, NO WIN32 headers, is 82 ms.

runperl.c, a 1.06 KB .c file, takes 500 ms to compile. Its not the Visual C compiler, since fcrypt.c was 82 ms. Its perl core specific problems. Refactoring/optimizing is needed.

[tonycoz]

I did some timing on my desktop, a AMD Ryzen 7 2700 (not new, not ancient), Windows 10 with 32GB RAM, SSD main drive (which is where the source and tools were), times in seconds for gmake -j4 CCTYPE=MSVC143 test-prep:

blead@5957de4f26

196.851972818375 197.28115606308 197.164458036423

22642

189.147753953934 189.534616947174 191.680377960205

Not sure why the last is so different, the machine had less than 20% CPU usage when the builds were running, it's possible the system started hitting the disk more for some reason.

I did a git clean -dxfq .. (in win32/) between each build.

So there's some improvement.

[bulk88]

Should this large set macros be made a public feature like PERL_NO_GET_CONTEXT or less relevant, NO_XSLOCKS, be documented maybe PERL_NO_GUI_H or PERL_NO_W32_GUI or PERL_NO_W32_GUI_H for XS devs/CPAN? and sprinkle it through P5P /dist modules and add it to ppport.h? it is a long canned list, and the vast majority of XS libs never need to pop up a Win32 GUI window or all these other APIs. perl core "Kernel32.dll" and "libc"/msvcrt/ucrtbase, and rarely winsock, is all that 99% of XS modules use, Win32 specific, or generic cross platform POSIX-ish XS modules.

It always has to be opt-in on CPAN just like PERL_NO_GET_CONTEXT to not break ancient CPAN code.