Skip to content
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

Developers can use Reflection APIs to easily access attribute-based metadata concepts #44319

Closed
1 task done
steveharter opened this issue Nov 5, 2020 · 7 comments
Closed
1 task done
Assignees
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Reflection Bottom Up Work Not part of a theme, epic, or user story Priority:3 Work that is nice to have User Story A single user-facing feature. Can be grouped under an epic.
Milestone

Comments

@steveharter
Copy link
Member

steveharter commented Nov 5, 2020

With various attributes being address to members and types, that information is cumbersome to access with reflection. These new APIs wrap access to that metadata and are intended to work both with runtime reflection and with MetadataLoadContext reflection.

Currently includes

Was prototyped, but not that much interest:

@steveharter steveharter added api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Reflection Team Epic labels Nov 5, 2020
@steveharter steveharter added this to the 6.0.0 milestone Nov 5, 2020
@steveharter steveharter self-assigned this Nov 5, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Nov 5, 2020
@jkotas
Copy link
Member

jkotas commented Nov 5, 2020

Do we also need more efficient low-level APIs to query custom attributes as part of this, to allow implementing these higher-level APIs efficiently on newer runtimes?

One has to enumerate all attributes and get a full name of each attribute today as you prototypes show: master...steveharter:ReflectionExt#diff-e4a922bf7ad13b0f5c1868bc798113844f672f9658fc0ac1b9c901e5893b6d61R25 . It looks pretty inefficient.

@steveharter steveharter removed the untriaged New issue has not been triaged by the area owner label Nov 5, 2020
@steveharter
Copy link
Member Author

On the performance, yes that was called out as will be poor.

I don't expect these methods to be called more than once for a given member, so perhaps it is OK. If they are called more than once, then currently higher-level caching would need to be used.

I believe the APIs would be called mostly by tooling and analyzers and not necessarily at run-time. If we need fast runtime support, some thoughts on caching:

  • Add a static hashtable for each type of extension method (would still be slow)
  • Add state to runtime types (would be more complicated, plus for each runtime and MetadataLoadContext)
  • Add state to TypeInfo (may still require a hashtable for per-member state)
  • Add "run-time attributes" that have the cached information (would be a new mechanism)
  • ...?

@jkotas
Copy link
Member

jkotas commented Nov 5, 2020

I don't expect these methods to be called more than once for a given member, so perhaps it is OK

Having an expensive APIs that are called just once for given member tends to be still a problem. Note that the real performance challenge for .NET runtime is startup, not steady state performance. Startup is where .NET is often much worse compared to alternatives.

I believe the APIs would be called mostly by tooling and analyzers and not necessarily at run-time. I

I do not think that these APIs are usable by analyzers. Analyzers do not use Reflection object model.

Are there concrete tools you have in mind outside analyzers for this?

@steveharter
Copy link
Member Author

steveharter commented Nov 6, 2020

Are there concrete tools you have in mind outside analyzers for this?

In the original issue @terrajobst points out EF and MVC as known scenarios.

The EF scenarios would use the nullability APIs to do things like generate a model from code which is generally not performant-critical since these are developer\design-time scenarios, not runtime\production scenarios.

The MVC scenarios may use for design-time scenarios too, but @terrajobst also mentions "model binding" scenarios which may imply runtime behavior and thus need high performance. However, perhaps that could be handled by generated code, which is influenced at code-gen time by the nullability information, so it may just be non-runtime\production scenarios as well.

@terrajobst is my assumption correct -- that the known users of these APIs do not need to be performant since they are not run in production? If not, and the APIs are called from run-time production code, then yes we'll need some sort of caching or a better (new) way to represent that metadata to make it fast.

@steveharter steveharter added Bottom Up Work Not part of a theme, epic, or user story User Story A single user-facing feature. Can be grouped under an epic. and removed Team Epic labels Nov 12, 2020
@danmoseley
Copy link
Member

@steveharter what should tihs be parented by - #44655 ?

@steveharter
Copy link
Member Author

@danmosemsft this issue could be combined with #44655; I originally planned on having 3 "team epic" issues including this one, #44655 and #44327. I wasn't sure on pros\cons of having separate vs together other than costing.

@danmoseley
Copy link
Member

danmoseley commented Nov 16, 2020

I think if a subset are cuttable together, and have much the same priority, it can make sense to keep them together in a separate issue. The purpose of the tree is to see what depends on what, see related work together, and cost and prioritize it in groups. Whatever we end up with, it's helpful to parent things somewhere.

@danmoseley danmoseley changed the title Add APIs to expose attribute-based metadata concepts Developers can use Reflection APIs to access attribute-based metadata concepts Nov 29, 2020
@danmoseley danmoseley changed the title Developers can use Reflection APIs to access attribute-based metadata concepts Developers can use Reflection APIs to easily access attribute-based metadata concepts Nov 29, 2020
@jeffhandley jeffhandley self-assigned this Jan 20, 2021
@jeffhandley jeffhandley added the Priority:3 Work that is nice to have label Jan 21, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Aug 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-suggestion Early API idea and discussion, it is NOT ready for implementation area-System.Reflection Bottom Up Work Not part of a theme, epic, or user story Priority:3 Work that is nice to have User Story A single user-facing feature. Can be grouped under an epic.
Projects
No open projects
Development

No branches or pull requests

6 participants