Return WIN32_NO_SOCKETS for miniperl.exe #22679
Conversation
ws2_32.dll loads msvcrt.dll and nsi.dll into the process unconditionally,
we dont need 2 CRTs in 1 process. proc start up time is important for
core building. About release perl. A future patch will come, but atleast
speed up the build is good.
This patch series made a benchmarkable drop in startup time. see numbers
below.
Macro was tested with full perl541.all and ws2_32.dll was totallly
removed/not linked in. My older code from some years ago, still loaded
ws2_32.dll on full perl, even tho sockets were not usable from PP. Now
that is fixed, but I doubt no sockets production perl is popular. But
optimization/feature now works on full perl too but very few use cases
for it for full perl.
Before
C:\sources\perl5>timeit miniperl -e "for(0..200){`miniperl -e\"1\"`}"
Exit code : 0
Elapsed time : 3.33
Kernel time : 0.37 (11.3%)
User time : 0.11 (3.3%)
page fault # : 9905
Working set : 6520 KB
Paged pool : 105 KB
Non-paged pool : 8 KB
Page file size : 6680 KB
After
C:\sources\perl5>timeit miniperl -e "for(0..200){`miniperl -e\"1\"`}"
Exit code : 0
Elapsed time : 3.11
Kernel time : 0.23 (7.5%)
User time : 0.05 (1.5%)
page fault # : 9852
Working set : 6308 KB
Paged pool : 104 KB
Non-paged pool : 7 KB
Page file size : 6616 KB
|
Assuming 200 miniperl invocations in a build, it saves 0.22 seconds while making the code more complex. The delayed sockets initialization is/was thread unsafe from what I can see. I don't think it's worth the added complexity. |
miniperl doesnt need access to winsock at anypoint, it never goes on the WWW and it has no use outside of blead/CC libperl time. at the original time of the 1st revision of this PR/patch/branch, this was patch 1 of 2, or 1 of 3, to bring back all of delay winsock features. But I plan a different way of bringing back the "no winsock in miniperl, delay winsock in full perl" feature than the way in revision 1.
C function The case of 2 random 3rd party different authors DLLs, loaded into one random Win32 process, and both 3P random DLLs executing If 2 perl ithreads both execute
I very strongly disagree. ws2_32.dll ALWAYS loads msvcrt.dll into perl.exe's virtual address space, but perl/perl XS ecosystem uses ucrtbase.dll nowadays. and ws32_32.dll's runtime overhead minimum malloc memory, and its couple 100/maybe 1000 upper end, count of Ring 0 kernel calls, to do DeviceIOCtl() calls to its parent kernel driver afd.sys and ring 0 calls to enumerate a ton of data out of the windows registry, is totally unnecessary for most perl processes. Also rpcrt4.dll and nsi.dll static linked, and something "ip helper .dll" forgot its real name but ip helper is required to enumerate NICs from user space and find a wired or wifi NDIS NIC to actually open as an object for sockets to work, all 3 absolutely dont need to sit inside perl.exes address space 24/7 and be loaded relocated, and run their DllMains and suck in a bunch of external state they need to operate from their DllMains. These extra DLLs also increase VS IDE's debugger process start/attach/SEGV debugger attach time by many seconds in the UI for me, because what was 3-4 DLLs 5 years ago, is now 18 EIGHTEEN DLLs inside Something I used to be able to do, which I can't do anymore in blead perl, is set a BP on winsock loading msvcrt.dll into address space and creating more HeapCreate() objects also makes the C dev user experience more noisy and difficult. delay loading of winsock was the best core self The startup time of nginix/lightspeed doesnt affect human developer time. I plan to reimplement the delay winsock loading feature in a totally different way than the way above/the previous way, without 20-45 Technically MS has a choice between DllMain or WSAStartup for 1x startup logic but its irrelavent what is done where, since nobody can recompile or publish a MS made system DLL. But theoretical things winsock must do 1x on startup, are at minimum enumerate the PCIe NICs and ethernet frame protocol handlers from the registry, register the current PID with afd.sys, and set up its own private TlsGetValue TlsSetValue slot, and go digging through address space if it can find a user32.dll in address space, and create its invisible GUI Window object/mess around with the Win32 GUI message packet event loop system. I dont think winsock does this in real life, but perhaps it also needs to talk to csrss.exe as part of its 1x startup code, using that rpcrt4.dll it loads, but again, the details don't matter since its a MS compiled DLL. Not loading the winsock DLL unless the process is going to communicate on WWW fixes all problems instantly. |
|
Why its a bad decision for WinPerl to unconditionally have Winsock library always loaded and running in a WinPerl process. Winsock static runtime links to the "secret" I have no easy way non-ASM way to benchmark the wall clock time cost of these destructors. Its probably 500 us to 1.5 ms max, maybe 5-10 ms on ancient HW. But there has to be a cost to that 1 millisecond, such as update: how nice, both UCRT and msvcrt.dll are both aware that WinPerl constantly does |
More destructors that get fired from DLLs that are not very useful to a TUI WinPerl process. Another stack, I dont remember what this DLL does off the top of my head, I think its an out-of-process RPC/message passing API between the consumer process and on screen keyboard producer process. |
Jeez. Why bother manually nuking Ring 0 opaque handles on process exit event? Perl has PERL_DESTRUCT_LEVEL, but that concept isn't a MS API design pattern. Wow |
8a548d1
Removed the optimization for miniperl.exe, build speed is important for new code. Bring back the macro for miniperl.exe only. Measureable time savings for me. see commit message.
??????????? maybe, its a small build perf opt