3

To increase performance I regularly find the need for inline expansion, unfortunately MethodImplOptions.AggressiveInlining is only available in .NET 4.5 and up. Are there any alternatives such as code snippets?

Leopold Asperger
  • 925
  • 1
  • 6
  • 12
  • 14
    I find the first phrase *extremely* difficult to believe. – Cody Gray - on strike May 24 '14 at 12:34
  • Do you regularly find the need to inline method for actual performance problem or because you just need to? If the former (which I doubt) you probably better change the language to a more performance oriented one (but probably it would be better to find better algorithms/design), otherwise you're doing a lot of work for really a small (if any) reward. – Fabio Marcolini May 24 '14 at 12:35
  • 1
    ~50% faster execution in some cases @fabio – Leopold Asperger May 24 '14 at 12:36
  • are you using Stopwatch to take the measures and calling the method one time before starting the measures to make it jitted? – Fabio Marcolini May 24 '14 at 12:44
  • I can only come up with a couple of explanations for that. Either (1) you tend to write extremely unusual methods that are too long for the typical inlining heuristics but somehow benefit from inlining regardless, or (2) you use try/catch blocks in every method, which prevents the JIT compiler from inlining the calls. I'm guessing #2 is most likely. – Cody Gray - on strike May 24 '14 at 12:45
  • yep, I do not include the first benchmark result @fabio – Leopold Asperger May 24 '14 at 12:46
  • Could you post an example of a method of yours that takes 25%-50% less time if inlined as you say? – Fabio Marcolini May 24 '14 at 12:47
  • @Cody neither of them are apply here. But for the note, we're talking about a method that is called within a loop that can continue for thousands of times. But if you want me to post an example to please your interest then I will be happy to do so. – Leopold Asperger May 24 '14 at 12:50
  • 1
    Well, I'm focusing on how to fix your *real* problem since I don't think there's a solution to the question you posted. Part of the design of C# (and the .NET Framework in general) is that there's no `inline` keyword (not that, even if there were, the compiler wouldn't freely ignore it). Instead, there's a JIT compiler that you trust to make the right decision. The overwhelming majority of the time, it does. If you're finding that it frequently doesn't, either you or Microsoft are doing something badly wrong. One of you needs to change your ways. – Cody Gray - on strike May 24 '14 at 12:52
  • @LeopoldAsperger only thousand of times? Do you actually have a performance problem on such code or not? I mean if you call it a thousand time and it takes 0.1msec without inlining and 0.05msec with inlining that's probably not a performance problem. – Fabio Marcolini May 24 '14 at 12:56
  • Thousands of times. There is no prominent performance problem, I'm competing with another library and eitherway ~50% is alot @fabio – Leopold Asperger May 24 '14 at 12:59
  • @LeopoldAsperger If you're competing for speed and there's no other place in your code taking a more time, it probably is. But in general a 50% difference is no big deal at least if we are not talking about a method that takes lot of time to complete but there the inline wouldn't solve the problem. – Fabio Marcolini May 24 '14 at 13:21
  • Its a really small method @fabio – Leopold Asperger May 24 '14 at 13:23

2 Answers2

2

It looks like you often write low-level performance-critical code. I find your question to be valid request. You like to have more control over when inlining happens. In fact, you would like to mark a certain call-site as forced for inlining.

Unfortunately, as of .NET 4.5 MethodImplOptions is the only way to control inlining. Furthermore, the .NET JIT is as of today a very poorly optimizing compiler. You can expect it to perform very basic optimizations like conservative inlining, dead code elimination and constant folding. It will not surprise you positively, though.

Alas, I can only give a negative answer. There is nothing you can do in the current version of the CLR.

What I noticed, though, is that you seem to append parsed chars one-by-one to some "buffer". Try to add them in bigger chunks. CPUs like copying memory in bigger units. Remember the position where the current text span started. When it ends, copy all chars in that span in one go (possibly using memcpy).

usr
  • 168,620
  • 35
  • 240
  • 369
  • 2
    Would like to find out the reason for the downvote. I cannot see anything that might be factually wrong here. – usr May 24 '14 at 13:46
0

Although I agree that often inline expansion is not the (best) answer for performance optimization, and thinking about the bigger picture can often yield much bigger gains, including removal of the whole method in question, sometimes it is the answer, and in that case, be it .Net 4.5 or not, you have to copy-and-paste code, i.e. inlining by hand, to be absolutely certain you get the effect you want, and on all platforms your app is being run. That's ugly, and unfortunately performance optimization often turns code ugly.

As you have discovered yourself with a method that looks like a perfect candidate for inlining.

Community
  • 1
  • 1
Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156