Skip to content

TestTP: Minor perf opt for ProvidedTypes.fs #18541

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

Merged
merged 1 commit into from
May 22, 2025
Merged

Conversation

Thorium
Copy link
Contributor

@Thorium Thorium commented May 10, 2025

Description

  • isNull is inline also in FSharp.Core. It's called in many places.
  • Lazy load of ILAssemblyRefs: There is no point in spending so much time initially to construct ilAssemblyRefs which is only used by GetReferencedAssemblies() call
  • Avoid looping 120 libraries through on most cases: Often convTypeRef is called to get some very basic base-type like a "System.Object" or "System.Int32" thus going through the dependency assemblies one-by-one can be a fall-back method rather than default implementation.

I would love to have some benchmark tests for ProvidedTypes.fs but the issue is that it's mostly used by FSharp.Compiler via a heavy IDE, and current unit-tests are not covering the majority of the process, so I don't have any idea how that could be done. Right now the best way seems to be to attach a VS to VS and open some type-provider and see what is going on.

- isNull is inline also in FSharp.Core
- Lazy load of ILAssemblyRefs
- Avoid looping 120 libraries through on most cases
Copy link
Contributor

✅ No release notes required

Copy link
Contributor

@KevinRansom KevinRansom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is a core part of the typeprovider SDK which is managed in: https://github.com/fsprojects/FSharp.TypeProviders.SDK

fsprojects/FSharp.TypeProviders.SDK#417

Is there some reason why it hasn't been merged there yet?

The file in this repo is a local fork. It would probably be best to make the change in it's real home, then port that file back to this repo, what do you think?

@github-project-automation github-project-automation bot moved this from New to In Progress in F# Compiler and Tooling May 12, 2025
@Thorium
Copy link
Contributor Author

Thorium commented May 12, 2025

I would expect it not to be merged because Don has more important things to focus on.
This PR does not change the external API at all.

Yes, I agree it could make sense not to maintain 2 copies of the file. Normally, I'd add the file as a Paket file reference, but Paket is not used here.

@Thorium
Copy link
Contributor Author

Thorium commented May 14, 2025

The PR in TP SDK side merged now.

@T-Gro T-Gro merged commit 8e3bb47 into dotnet:main May 22, 2025
33 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in F# Compiler and Tooling May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants