small .h trick for faster win32 interp compiles, cl.exe in the prompt is #22642
Conversation
|
What does "cl.exe in the prompt is much faster eye" mean? |
|
If anyone later does need any of the functionality you're leaving out now, can they do that? |
I assume it's faster "by eye"
It only limits the APIs declared under PERL_CORE, If we (perl core) need APIs this suppressed we can remove the The change really needs the defines and inner pre-processor conditionals indented to make what's guarded by the conditionals obvious. |
Yeah then that doesn't matter.
I agree that would make it easier to read. |
|
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:
The numbers are pretty much just noise. I'm not sure what "much faster" means, but I don't see it here. |
cl.exe in the terminal is much faster by 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. Since CPAN has been caught doing "-DPERL_CORE" in the past then including p5 core headers, include a provision to enable #include full W32 headers, since it might be difficult to #undef then #include the OS headers a 2nd time with different CPP defines. "#define NONLS" too many core interp .c files need the ANSI/Wide code page apis to special case each .c. Just leave it out for now. A benefit is smaller .pdb or whatever GCC's dbg symbol file format is. So faster debugger startup. Also GCC uncontrollably includes all "#define"s in its symbol disk format (which isnt a separate file, but a many MBs memory mapped data structure embedded into the particular .exe or .dll, on disk, and in VM). Since Perl isn't a Win32 GUI app, keep the GUI APIs out of the compiler if possible and toss the "text" ASAP in the phases of compiling. Whether whole MS .h files are skipped, or CPP discards large chunks of APIs before reaching the C parser/.obj/.pdb files, is implementation specific behaviour by particular MSVCs and Mingw. Our side was completed, in requesting to exclude stuff.
bulk88
force-pushed
the
win32osheadersperf
branch
from
c205abc to
3eec7ec
Compare
|
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. |
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: 379 seconds, 6.3 mins for me |
|
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 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. |
|
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 blead@5957de4f26 196.851972818375 22642 189.147753953934 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 So there's some improvement. |
|
Should this large set macros be made a public feature like It always has to be opt-in on CPAN just like |
|
bump |
|
bump |
|
Some research, I am not the only person complaining Other FOSS are very unhappy at the amount of child https://listarchives.boost.org/Archives/boost/2002/02/25800.php another post discussing chopping up the official MS headers during compile time (using Perl!) . |
5 participants
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.