> It sounds like the same issue exists with this approach of removing unused libraries and binaries that have not been run in a while. Not really, it's the dif

> It sounds like the same issue exists with this approach of removing unused libraries and binaries that have not been run in a while. Not really, it's the difference between knowing that something isn't plugged in and hoping that it isn't powered on. Libraries that aren't run are deleted, you're suggesting to expand this to stochastically unexercised code paths within libraries that are run. (as opposed to provably unexcercisable code paths, which I think there are tools that do do this but are opt-in instead of on-by-default). > If code isn't run that means that it isn't providing value or it isn't being tested in production. Or can't show up in profiling for any number of reasons (I'm immediately brought to the idea of a CHECK fail which would not every show up in profiling I don't think, but could be exercised regularly, and if is included intentionally is likely preventing some kind of data corruption issue so removing it would be terrible).