Investigate using Auto layout for structs in the framework

[GSPP]

By default, the C# compiler marks structs [StructLayout(LayoutKind.Sequential)]. I believe the historic reason for this is that structs were assumed to be mainly for interop. Unfortunately, this can cause unnecessary padding (and possibly other inefficiencies?).

The default in the C# language cannot be changed because large bodies of existing code depend on this behavior.

Even if the struct itself does not benefit from Auto, the runtime can rearrange fields together with surrounding structs: #7720 (comment). It's therefore not enough to look at a struct definition to conclude that it is not beneficial to mark it Auto. Profitability depends on usage as well.

I wonder if it can be considered a performance best practice to routinely mark all non-interop structs as LayoutKind.Auto. This strategy does not seem to have a downside except for the code clutter that this brings.

Would it be worth adopting a policy in which all eligible structs are marked as Auto? Should there be an analyzer for that?

This policy would be in contrast to making case-by-case decisions. The benefit is simplicity and ease of code review. "If the attribute is missing, it's a bug."

I loaded all system assemblies and made lists for how the struct layout is currently set:

5.0.8 Auto.txt
5.0.8 Explicit.txt
5.0.8 Sequential.txt

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[stephentoub]

Are there specific cases where you see there'd be a tangible benefit? Many of the examples in your Sequential.txt are for interop and making them non-sequential would break the functionality. Many others in Sequential.txt have only a single field and wouldn't benefit from a different layout. Still others have all fields of the same type and there'd be no benefit to a different layout. Others are already in the optimal order. Still others are typically only used on the stack and a few extra bytes here or there on the stack aren't going to be meaningful. I appreciate your interest here, but just outputting a list of all structs isn't particularly actionable.

As for an analyzer, I expect it'd be hard to get it "right". Sequential is the closest there is to a "safe" option, in case the dev is doing something that expects that visible layout, whether that be interop or pointer-based access to fields or Unsafe casting, and without a lot of case law demonstrating it's worth forcing Auto to be used, I suspect it'd cause more harm than good, even if that "harm" is noise because there's no real benefit to the different layout being required.

This issue has been marked needs-author-action since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[GSPP]

Right, I have no concrete reason to believe that any of these cases would benefit. I am not qualified to make that assessment. My thinking is more about changing policy on this. I generated the files just as a convenience for auditing the current state. It's not meant to be an actionable list.

... and without a lot of case law demonstrating it's worth forcing Auto to be used ...

That's probably the critical point here. Is there a systemic benefit, or is it just a small benefit here or there? You are far better able to tell than I am, so if you don't think there's anything to do here, I wouldn't mind closing the issue. I just wanted to bring this to your attention.

[AaronRobinsonMSFT]

I am dubious of the value of providing this guidance and the optimizations it may enable are likely very small or niche. That being said this does seem like an area where we should have a concrete understanding of when packing non-interop structs is beneficial. I think an investigation is warranted, whether that is done by the community or Interop team is TBD so I'll place this in "Future".