Repository navigation
Pyshellext room for binary size improvement #84326
Description
| BPO | 40145 |
|---|---|
| Nosy | @pfmoore, @tjguk, @zware, @zooba, @ariccio |
| PRs |
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:
assignee = None
closed_at = None
created_at = <Date 2020-04-01.22:43:57.522>
labels = ['3.9', 'OS-windows']
title = 'Pyshellext room for binary size improvement'
updated_at = <Date 2020-04-03.22:17:34.747>
user = 'https://github.com/ariccio'bugs.python.org fields:
activity = <Date 2020-04-03.22:17:34.747>
actor = 'steve.dower'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2020-04-01.22:43:57.522>
creator = 'Alexander Riccio'
dependencies = []
files = []
hgrepos = []
issue_num = 40145
keywords = ['patch']
message_count = 6.0
messages = ['365527', '365543', '365603', '365724', '365725', '365731']
nosy_count = 5.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'Alexander Riccio']
pr_nums = ['19284', '19298']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue40145'
versions = ['Python 3.9']
Activity
ariccio commentedon Apr 1, 2020
I've tweaked the pcbuild options for pyshellext to reduce the size of the binary.
Since this is a very simple component, there really isn't much benefit of
optimizing for speed, likely the slowest part of this component's lifetime is
simply loading it.
This patch turns on Whole Program Optimization, MinSpace optimization, /Ob2
AnySuitable function inlining (to expose more code to elimination, this does
actually help here), /Zo (so that people can still debug it when lots of code
has been optimized out), turns of C++ RTTI (nobody is using it), /OPT:REF dead
code elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and
DebugFull debugging information creation.
/Gw global data optimization seemed to do nothing, which makes sense since
there isn't much going on in this project, very little in the way of actual
global data. Disabling C++ exceptions both in the project config (i.e. /EH-),
and disabling stdlib exceptions via _HAS_EXCEPTIONS=0, had no effect.
Strangely, with exceptions disabled and _HAS_EXCEPTIONS=0, exception functions
are still emitted in the binary (as seen in IDA). I presume it has something
to do with the fact that its a dll.
Enabling optimizations (even for Debug builds) should have no effect. The debug
builds were not actually using debugging featuers (not even assert), so nothing
should change.
pyshellext.dll 32 bit unimproved release size: 42KB
pyshellext.dll 32 bit improved release size: 25KB
size reduction: -17KB
% size reduction: 40%
pyshellext_d.dll 32 bit unimproved debug size: 85KB
pyshellext_d.dll 32 bit improved debug size: 32KB
size reduction: -53KB
% size reduction: 62%
pyshellext.dll 64 bit unimproved release size: 52KB
pyshellext.dll 64 bit improved release size: 30KB
size reduction: -22KB
% size reduction: 42%
pyshellext_d.dll 64 bit unimproved debug size: 105KB
pyshellext_d.dll 64 bit improved debug size: 38KB
size reduction: -67KB
% size reduction: 63%
ariccio commentedon Apr 2, 2020
If this patch is merged, and all 7 million (estimated) Python developers update their installation, I calculate that I just saved the PSF 119GB worth of bandwidth costs :)
I'll take my 10 cents in the mail please :D
zooba commentedon Apr 2, 2020
I'm seeing some numbers that suggest it's even bigger than 7 million, so you might be deserving of more! Of course, that bandwidth is a donation, so you'll have to apply to Fastly ;)
Our MSBuild projects are hand-maintained (often by people on non-Windows systems). Could you tidy the XML to minimize the "Condition" attributes? And as much as is reasonable, move defaults into pyproject.props and per-project overrides in the specific projects?
ariccio commentedon Apr 3, 2020
Ahh, ok. Even though I question the usefulness of manually maintaining MSBuild files instead of something like CMake, I can work with that. Is there a preferred way to do it? It looks like I can do a Condition="'$(Configuration)|$(Platform)'=='Release|x64'" and merge a bunch of things under each one.
ariccio commentedon Apr 3, 2020
Oh, uh, also, do you prefer I add a commit or a new branch & PR?
zooba commentedon Apr 3, 2020
In general, no settings rely on both Platform AND Configuration, so you likely only need to check one or the other.
Look at PCbuild/pyproject.props for the best examples. IIRC, properties are set assuming Win32/Release, and then we override those that need to be different for either Debug or x64/ARM builds. Any settings that you think are worth applying to all projects can go in this file, while any that are strictly for pyshellext can go in its vcxproj (but using a similar style).
Let's not start a CMake debate here - there are plenty of other issues on here about that. We currently maintain MSBuild files by hand, and it works well.
More commits on the same PR are fine. We squash merge at the end, so the history only remains in the commit message if we need to put it there.
zware commentedon Oct 20, 2026
It turns out that we solved this by reducing the size to 0;
pyshellext.vcxprojwas removed entirely in GH-153512.zooba commentedon Oct 21, 2026
It was moved to the pymanager repo, where it probably grew larger 😉