1

In C#, you can apply the [MethodImpl(MethodImplOptions.AggressiveInlining)] attribute to any method to ensure that the JIT inlines calls to it in most places (as opposed to relying on heuristics recognising short methods). When it should be applied is controversial, but modern .NET generally does well enough on its own that the attribute isn't necessary. (Sadly I'm stuck working with .NET Framework.)

I'm curious whether it has any effect on finalizers (destructors, ~TypeName() {}), seeing as they can take any attribute applicable to AttributeTargets.Method, including [MethodImpl]. From the docs, I gather that the GC calls each Finalize implementation going up the class inheritance chain—would these calls be eligible for inlining? Not that I expect it would make a noticeable difference if so.

Improve this question
2
  • This may seem like a stupid question, and if so I apologise. Why are you writing finalizers? What are they doing? Commented Oct 28, 2024 at 21:35
  • 1
    @mjwills I swear I'm using them properly! In fact the only time I recall writing one was for a collection class which Rented a buffer from ArrayPool.Shared if one wasn't supplied in the ctor, and Returned it upon GC. Commented Oct 29, 2024 at 15:39

1 Answer 1

Reset to default
3

No.

This is mostly due to how the C# compiler ensures that the whole inheritance chain is walked for all the Finalizer methods. The compiler generates a try-finally block:

try { // Derived Finalizer code goes in here } finally { base.Finalize(); }

And methods containing try-(catch)-finally blocks are not eligible for inlining according to this (old) source cited in this so question. The answer provides a good explanation as to why this makes sense.

This is still the case for .NET 8 - sharplab link

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.