-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove shlwapi dependency on Windows #89883
Comments
According to https://twitter.com/BruceDawson0xB/status/1455714820485894151?s=20 there are some serious performance implications from referencing shlwapi.dll. It turns out, we only use it for one native path calculation function, which is easily replaceable (since Windows 8). So we can drop the dependency and get a startup (and shutdown) improvement back to 3.9. |
FTR, I see about 1-1.5ms improvement (using timeit to do a check_call) out of ~32ms total startup time. I also don't actually see gdi32 being transitively loaded as claimed in the Twitter thread, even back to 3.8. So presumably there's something else going on to cause that issue. Either way, this is an easy change with non-zero benefit (at the very least, it gets rid of a dependency we are better off avoiding these days). |
Since Windows XP, shlwapi.dll has increasingly made use of delay loading, but up to Windows 8.1 it was still immediately loading user32.dll and gdi32.dll. In Windows 10, shlwapi.dll finally made them delay loaded dependencies. Also, in Windows 10, PathIsRelativeW is forwarded to the implementation in kernelbase.dll, not that it matters from the end user's perspective since it's not in an API set. Regarding user32.dll, there's still an issue with ssl, hashlib, winsound, and ctypes not delay loading it, or DLLs that directly depend on it such as ole32.dll and oleaut32.dll. In most use cases these DLLs would never be loaded. When user32.dll loads, the process and the loading thread are converted to GUI versions, i.e. they're extended in the kernel with the window manager's Win32Process and Win32Thread structures, and the process connects to a window station and desktop (e.g. r"WinSta0\Default"). One concern with converting to a GUI process is that the system doesn't send CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT console events to GUI processes. Thus a console script can't handle those events with a simple ctypes-based handler as long as importing ctypes always loads user32.dll. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: