Note that the changes in the builtin collections from "speed" and "size" to "favor_size" actually is just a rename, the functionality is the exact same between the old and new. I think many of these uses were actually added while the writer was under the impression that they matched their respective -o: flag though, so they may need further review on which ones are actually wanted.
I also have implemented (besides a race condition) solution number 3 described in that issue, where the different optimisation modes are collected into their own module and optimised separately, this works well, but without link time optimisation it is not going to be beneficial in many cases (these modules don't know about each other so they can't make optimisations based on that knowledge, nor can they inline things across the boundary). That solution is worth revisiting when/if we do have link time optimisations in the future.
Resolves #3891
Note that the changes in the builtin collections from "speed" and "size" to "favor_size" actually is just a rename, the functionality is the exact same between the old and new. I think many of these uses were actually added while the writer was under the impression that they matched their respective
-o:flag though, so they may need further review on which ones are actually wanted.I also have implemented (besides a race condition) solution number 3 described in that issue, where the different optimisation modes are collected into their own module and optimised separately, this works well, but without link time optimisation it is not going to be beneficial in many cases (these modules don't know about each other so they can't make optimisations based on that knowledge, nor can they inline things across the boundary). That solution is worth revisiting when/if we do have link time optimisations in the future.