microsoft / winfile

Original Windows File Manager (winfile) with enhancements
MIT License
6.75k stars 698 forks source link

XP builds - use /O1 optimization #428

Closed wesinator closed 3 months ago

wesinator commented 3 months ago

suggest using /O1 flag for XP builds

schinagl commented 3 months ago

Nowadays MinSpace/MaxSpeed doesn't matter that much.

With this project you gain a few kB or a few micro-seconds here and there. Both will not have a significant impact on the user experience

wesinator commented 3 months ago

I figured the space counts more with the XP (IA32) static build. 845kb vs 875kb I know it's not much (~3.4% reduction)

malxau-msft commented 3 months ago

Fwiw, I agree with both of you. 30Kb is just not enough to matter on any user visible metric - disk space, available RAM for caching, disk transfer time, download time, etc. On the other hand, given that Winfile is pretty much a wrapper for OS UI and file system primitives, it doesn't contain any tight CPU loops, and any compute optimizations won't be much use either.

More generically though, I remember seeing an investigation into Vista performance showing a 6% perf win by optimizing for space over speed. It turns out that fitting code into memory or cache constrained system is often more important than efficient computation - most code isn't looping within the L1 instruction cache.

wesinator commented 2 months ago

FWIW, I was able to get another ~7.3% size reduction by using the VC-LTL package for the build.

malxau-msft commented 1 month ago

FWIW, I was able to get another ~7.3% size reduction by using the VC-LTL package for the build.

How does VC-LTL work? From the documentation, it sounds like it dynamically links to the XP msvcrt.dll and provides statically linked functions for anything which has been updated since?

If so, that's how the Windows/WDK build environments used to work - it's possible to use the Windows 7 compilers and libraries, add msvcrt_winxp.obj, and it will statically link anything the newer compilers expect while leaving XP's msvcrt.dll to pick up the rest. This seemed to end after Windows 7 (newer releases stopped attempting to update msvcrt.dll to support newer compiler functions anyway.)