This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Pyshellext room for binary size improvement
Type: Stage: patch review
Components: Windows Versions: Python 3.9
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2020-04-01 22:43 by Alexander Riccio, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 19284 open Alexander Riccio, 2020-04-01 22:49
PR 19298 closed Alexander Riccio, 2020-04-02 03:55
Messages (6)
msg365527 - (view) Author: Alexander Riccio (Alexander Riccio) * Date: 2020-04-01 22:43
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%
msg365543 - (view) Author: Alexander Riccio (Alexander Riccio) * Date: 2020-04-02 00:52
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
msg365603 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-02 16:31
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?
msg365724 - (view) Author: Alexander Riccio (Alexander Riccio) * Date: 2020-04-03 21:43
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.
msg365725 - (view) Author: Alexander Riccio (Alexander Riccio) * Date: 2020-04-03 21:44
Oh, uh, also, do you prefer I add a commit or a new branch & PR?
msg365731 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-04-03 22:17
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.
Date User Action Args
2022-04-11 14:59:28adminsetgithub: 84326
2020-04-03 22:17:34steve.dowersetmessages: + msg365731
2020-04-03 21:44:56Alexander Ricciosetmessages: + msg365725
2020-04-03 21:43:37Alexander Ricciosetmessages: + msg365724
2020-04-02 16:31:31steve.dowersetmessages: + msg365603
2020-04-02 03:55:50Alexander Ricciosetpull_requests: + pull_request18659
2020-04-02 00:52:57Alexander Ricciosetmessages: + msg365543
2020-04-01 22:49:16Alexander Ricciosetkeywords: + patch
stage: patch review
pull_requests: + pull_request18642
2020-04-01 22:43:57Alexander Ricciocreate