Skip to content

Automagically remove F# compilation resources #329

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dsyme opened this issue Jul 3, 2018 · 6 comments · Fixed by #1040 · May be fixed by dotnet/runtime#115116
Open

Automagically remove F# compilation resources #329

dsyme opened this issue Jul 3, 2018 · 6 comments · Fixed by #1040 · May be fixed by dotnet/runtime#115116
Labels

Comments

@dsyme
Copy link

dsyme commented Jul 3, 2018

The linker can/should automatically remove any .NET manifest assembly resources named FSharpSignatureData.* and FSharpOptimizationData.* during linking.

These are only ever needed for F# compilation which doesn't happen on-device and given the aims of the linker it is reasonable to assume this data is unreachable.

My understanding is that removing these would trim about 1.5MB off the size of all applications using FSharp.Core.dll, and about 3MB off all applications using Elmish.XamarinForms.dll.

Here's an example of how the resources look in ILDASM:

    .mresource public FSharpSignatureData.Elmish.XamarinForms
    .mresource public FSharpOptimizationData.Elmish.XamarinForms

Thanks

@nosami
Copy link

nosami commented Jul 3, 2018

I think we need an option to preserve the resources as @praeclarum's Continuous IDE does do F# compilation on device.

That's the only app that I am aware of that might break.

@dsyme
Copy link
Author

dsyme commented Jul 3, 2018

Yes. I'm still amazed that works. We could recommend that that app bundle a private copy of FSharp.Core but I'm also ok with there being an appropriate option

@radekdoulik
Copy link
Member

We can extend the custom linker xml definition to be able to preserve resources as well and remove these by default

@Numpsy
Copy link

Numpsy commented Apr 24, 2025

Question: Could/Should this linker functionality be extended to strip the new compressed equivalents of these resources (which have different names?)

refs dotnet/fsharp#15605 dotnet/fsharp#17995

@T-Gro
Copy link
Member

T-Gro commented Apr 28, 2025

Yes, it should.
The names which can appear in a F# assembly are:

FSharpSignatureData.*
FSharpSignatureDataB.*
FSharpSignatureCompressedData.*
FSharpSignatureCompressedDataB.*

FSharpOptimizationData.*
FSharpOptimizationDataB.*
FSharpOptimizationCompressedData.*
FSharpOptimizationCompressedDataB.*

FSharpOptimizationInfo.*
FSharpSignatureInfo.*
[the last 2 can only ever appear on FSharp.Core and has a different name for historical backwards compat reason, but then also FSharp.Core is what will be present in all compilation units]

@T-Gro T-Gro reopened this Apr 28, 2025
@T-Gro
Copy link
Member

T-Gro commented Apr 28, 2025

x.StartsWith("FSharpSignature") || x.StartsWith("FSharpOptimization")

Should cover all 10 possibilities.

T-Gro added a commit to dotnet/runtime that referenced this issue Apr 28, 2025
The original solution was missing 3 further dimensions of F# resourced:
- Being compressed or not
- Being part of FSharp.Core (STD lib for F#) or user code
- Being original stream or a backwards-compatible stream for newer language features, particulary nullable reference types

The full set of supported prefixes currently is:
FSharpSignatureData.*
FSharpSignatureDataB.*
FSharpSignatureCompressedData.*
FSharpSignatureCompressedDataB.*

FSharpOptimizationData.*
FSharpOptimizationDataB.*
FSharpOptimizationCompressedData.*
FSharpOptimizationCompressedDataB.*

FSharpOptimizationInfo.*
FSharpSignatureInfo.*


This closes dotnet/linker#329
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
6 participants