Quick Question: Do inline arrays require intra-index padding?

[toupswork]

Can you confirm whether inline arrays, unlike stackalloc, require intra-index padding unless all elements have a 1-byte alignment (e.g., byte)? If so, does this mean inline arrays often consume more stack space than stackalloc, as they may require padding not just at the beginning or end but also between elements?

Additionally, aside from their intended use in P/Invoke scenarios, do inline arrays have significant practical applications?

Thank you in advance for your insights!

[333fred]

Moved over to the runtime; the C# language does not care anything about padding or struct sizes.

[toupswork]

After analyzing the JIT x64 assembly of an example C# code, I have reached a conclusion

Sample C# Code

using System;
using System.Runtime.CompilerServices;
class Program {
    static void Main(){
        Test t = default;
        t.Index0 = t.Index1 = t.Index2 = t.Index3 = 3;
        t.ToString();
//
        Buffer<int> b = default;
        b[0] = b[1] = b[2] = b[3] = 1;
        b.ToString();
    }
}
[InlineArray(4)]
public struct Buffer<T> { private T _element0; }
// regular struct
public struct Test { public int Index0, Index1, Index2, Index3;  }

x64 Assembly

Program:Main() (FullOpts):
G_M27646_IG01:  ;; offset=0x0000
       push     rbp
       mov      rbp, rsp

G_M27646_IG02:  ;; offset=0x0004
       mov      rdi, 0x7E64A8804008      ; Test
       call     CORINFO_HELP_NEWSFAST
       mov      dword ptr [rax+0x08], 3
       mov      dword ptr [rax+0x0C], 3
       mov      dword ptr [rax+0x10], 3
       mov      dword ptr [rax+0x14], 3
       mov      rdi, 0x7E6522201578      ; 'Test'
       mov      esi, 1
       call     [System.RuntimeType:GetCachedName(int):System.String:this]
       mov      rdi, 0x7E64A891EAC0      ; Buffer`1[int]
       call     CORINFO_HELP_NEWSFAST
       mov      dword ptr [rax+0x08], 1
       mov      dword ptr [rax+0x0C], 1
       mov      dword ptr [rax+0x10], 1
       mov      dword ptr [rax+0x14], 1
       mov      rdi, 0x7E6522202B50      ; 'Buffer`1[System.Int32]'
       mov      esi, 1
       call     [System.RuntimeType:GetCachedName(int):System.String:this]
       nop      
G_M27646_IG03:  ;; offset=0x0085
       pop      rbp
       ret      

Analysis

Feature	Test (Regular Struct)	Buffer (Inline Array)
Total Size	16 bytes	16 bytes
Field Layout	int[0] at 0x00, int[1] at 0x04, int[2] at 0x08, int[3] at 0x0C	int[0] at 0x00, int[1] at 0x04, int[2] at 0x08, int[3] at 0x0C
Intra-Padding	None	None
Alignment Constraints	None beyond natural int alignment	None beyond natural int alignment

Conclusion

• Test and Buffer have identical layouts: 16 bytes, 4 int fields, no intra-padding.
• Padding only occurs if the struct as a whole is misaligned, not between elements.
• InlineArray behaves just like a struct with repeated fields in terms of layout.

[jilles-sg]

The elements of regular arrays, inline arrays and stackalloc can be described by the same Span<T>, so if the layout of the elements differed between those three cases it would be really expensive. As implemented in .NET, access to a span does not care what the span was created from.

As for uses of inline arrays, they could be used as a replacement for stackalloc that also allows managed types and more generally if a fixed number of elements is needed (which may not be particularly common). However, exposing an inline array as such in a public API seems unwise because of its weird conversion to span. Also, they interact poorly with collections (IEnumerable<T>, etc.) and async code.

If an inline array is used as a field of a class or other longer-term data structure, it may improve locality and reduce memory consumption slightly (compared to a regular array) but in a way which is hard for compilers to do automatically. For example, if the actual data of the array is small compared to the overhead of an object reference and object header and the number of instances is large.

[toupswork]

The elements of regular arrays, inline arrays and stackalloc can be described by the same Span<T>, so if the layout of the elements differed between those three cases it would be really expensive. As implemented in .NET, access to a span does not care what the span was created from.

This is such a great observation! It makes total sense. At the time I wasn't thinking about how they could be used with a span, and I wasn't sure if there were edge cases that would permit it spans to skip over padding. In hindsight, this is a quite a compelling argument that, had it entered into my consciousness, would have stopped me in my tracks from coming on here and questioning the intra-index padding in the first place.

As for uses of inline arrays, they could be used as a replacement for stackalloc that also allows managed types and more generally if a fixed number of elements is needed (which may not be particularly common).

Yes. And of course, it can allow for more types than can stackalloc, but as you mention, it would be difficult for me to think of a reason why an informed developer would do that intentionally.

However, exposing an inline array as such in a public API seems unwise because of its weird conversion to span. Also, they interact poorly with collections (IEnumerable<T>, etc.) and async code.

Yes! And considering how there are libraries that provide IEnumberable<T> type support for Spans, especially given the new C# 13 allows ref struct, which I understand provides additional permissibility when it can be proven it could not escape the original stack frame, that may be solved by 3rd party Nuget if not already.

And to go along with your mention of async, if one were to use an inline array as a way to circumvent the restriction that Spans cannot be used in iterator or async methods, it should be noted that if it were to cross an await boundary, it would be stored on the heap, which could negate any possible or intended performance increase.

If an inline array is used as a field of a class or other longer-term data structure, it may improve locality and reduce memory consumption slightly (compared to a regular array) but in a way which is hard for compilers to do automatically. For example, if the actual data of the array is small compared to the overhead of an object reference and object header and the number of instances is large.

That is such a fantastic point! Data locality and density can have large performance increases for a variety of reasons, including CPU cache, the TLS buffer, and read-ahead. Your point challenges my thought that you would not want to put an inline array on the heap with a strict interpretation. And even though reference-type arrays, where the array type is a value type, have their values stored inline and contiguously, as opposed to a sequence of managed pointers for reference types, the field holding that array would need to be dereferenced from the class which contains an instance of it, so it won't not have the same level of data locality.

In conclusion, because you decided to donate time out of your busy day to pen this wonderfully written and cogent response, you have benefited me by broadening my knowledge, integrating concepts from different domains, challenge assumptions, and improve my critical thinking. This information will only help me as a developer. I very much appreciate what you have done.

[huoyaoyuan]

InlineArray behaves just like a struct with repeated fields in terms of layout.

This is specifically called out in the design of inline array: https://github.com/dotnet/runtime/blob/main/docs/design/features/InlineArrayAttribute.md

Unlike "filed0; field1; field2;..." approach, the resulting layout would be guaranteed to have the same order and packing details as elements of an array with element [0] matching the location of the single specified field. That will allow the whole aggregate to be safely indexable/sliceable.