Open marek-safar opened 6 years ago
migueldeicaza
commented
6 years ago Notes:
marek-safar
commented
6 years ago SRE should be removed by a linking stage, so we should figure out what is keeping it around
I don't think we have simple way to remove SRE from XA runtime by linker and we'll hit the same problem on XI once we enable interpreter.
Before we spend a lot of time doing some of these things like
The work has been done on some features and we are working together on more with CoreFX folks. However, the way how they have done so far would require static analysis linker support which we don't have. Secondly, this is not about code which we can easily remove. This is about explicit settings selected by the users with features like non-file URI resolving functionality in XmlUrlResolver, something similar we did with codepages.
You can see the proposal at https://github.com/dotnet/designs/pull/42/files
The CoreFX source code import and some new features like the interpreter have had a negative impact on the final binary size of binaries we produce for Xamarin scenarios. The size we care about is not the Mono libraries size but the final size of customer's app once all tools used to reduce the size are applied. We never tracked this continuously which is one of the reasons we regressed.
Most if not all tasks bellow will have a positive impact on the size and could be done separately. The one which will require significant effort will be extracted to the sub-tasks.
Infrastructure improvements
ILLinker improvements
Runtime improvements
BCL improvements
Many of the tasks here could be automated at least from the analysis perspective. We should build tools for them as it's very likely we'll have to repeat them every time we update any of our dependencies.
Major BCL size regressions