3 ms·
> How would a smaller shared object lead to faster startup? The kernel isn't loading pages to memory unless they're actually used. IDK on linux but on windows
by jcelerier 3y ago
> How would a smaller shared object lead to faster startup? The kernel isn't loading pages to memory unless they're actually used.
IDK on linux but on windows opening a 600mb exe (e.g. release with debug info) and a 15mb one (same but stripped) have a VERY OBVIOUS startup time difference. I assume the OS is scanning the whole binary through some antivirus for instance, and I'd assume the same to be true for DLLs used by the app, so all these kernel loading pages optimizations go through the trash.
- mgaunard 3y agoThat's ridiculous. It's frequent for a process to map large amounts of data from the disk. Requiring that this data be eagerly loaded and be present in memory at all times would be disastrous for performance, if even possible. Even Windows wouldn't do something so silly.
- slaymaker1907 3y agoAre you using symbol files? I thought most debug info on Windows was put in those, not in the binary itself. We include some debug info with SQL Server, but not symbol files, so that we can debug crashes from production deployments.
- dblohm7 3y ago+1 - they're probably using the wrong compiler flags.
- fweimer 3y agoI'd expect this to be related to virus scanning. It's hard to use demand paging for that.