-2

I was just wondering where there any downsides to using in method argument from c# 7.2 I know this is recommended for dealing with Structs and they say it won't increase performance that much but from what I can tell this won't have any negative impact on the code and might help you with stack overflow exceptions when doing recursions. Dose anyone know of a good reason why all methods should not be marked as in? I found why people recommend to avoid ref and out but they don't work here.

Filip Cordas
  • 2,531
  • 1
  • 12
  • 23
  • With `in` you can explicitly tell the parameter won't be changed. So it depends on the situation i suppose – EpicKip Mar 27 '18 at 13:17
  • @EpicKip That what I was wondering what situation is not putting in on a parameter better? I am unable to think of any. – Filip Cordas Mar 27 '18 at 13:22
  • When it might be changed? Also when it being changed won't matter at all. Or where it clear that the parameter is just input, for example a `Create()` method usually will not alter the parameters so you wouldn't have to explicitly specify – EpicKip Mar 27 '18 at 13:24
  • for example, when reference is bigger than object itself, so making a copy is cheaper. – Tigran Mar 27 '18 at 13:26
  • @Tigran That makes sense. Do you know of an situation when this might happen? – Filip Cordas Mar 27 '18 at 13:29
  • Think in C/C++ is easier if you know about it. The `in` is almost same with const pointer(reference). `ref` is non-const pointer(reference). It means that if not mark `in` or `ref`, the parameter will fully copy to stack again. Therefore it can cause stack overflow if the parameter size is huge. `in` does not allow to write the referencing memory. It is different with `ref`. –  Mar 27 '18 at 13:35
  • It was *meant* to help programmers write more efficient code. But it is just as likely to produce less efficient code. The refactoring is unpleasant, you have to rewrite a class to a struct, ensure that methods don't try to mutate it and focus on storing it in a local variable instead of the heap. Bunch of work, you might still not be ahead. Don't start on it until a profiler showed you a bottleneck. The ref features, as well as Span, came out of Roslyn. They had a tough job, beating a C++ version that was perf-tuned for over a decade with immutable types in C# was not easy. – Hans Passant Mar 27 '18 at 13:52

1 Answers1

1

As this is a performance related question, as a matter of discussion in was introduced for that reason, it's hard to find single, correct answer, without really measuring performance on concrete code sample.

But...

We know that in creates a reference which is 32bit on x86 OS, and 64bit on x64 OS.

Now consider a structure like 

struct Token
{
    char x; 
}

on x64 OS, copy this structure on the stack, likely, will execute faster, than creating 64bit reference to the same data.

Plus, do not forget, that in implies "constantness" on an instance, which goes beyond performance reasoning, and targets directly your design. Hence, while from performance related matters, some of reasoning might be arguable, from design point of view, in has distinct and clear semantics to target specific design use cases.

Tigran
  • 61,654
  • 8
  • 86
  • 123