Are unnecessary braces reducing performance?

Question

After you came across this while programming, I was curious about this. Below are 2 snippets that are legal and compiled. In particular, my question is this: in the second case, do the parentheses make the program slower? Also why is this allowed?

1st case:

if (statement) { // do something } 

Second case:

 { if (statement) { // do something } } 

Also, what if I had something like the code below .. Is the runtime the same as just the calling function X without any curly braces.

 { { { // call function X } } } 

Answer 1

In most cases, it does not matter - and you should definitely code for readability more than anything else.

However, braces can unexpectedly affect performance, although this is rather unusual. Consider this code:

 using System; using System.Collections.Generic; class Test { static void FewerCurlies() { List<Action> actions = new List<Action>(); for (int i = 0; i < 100; i++) { int x; if (i % 3 == 0) { actions.Add(() => x = 10); } int y; if (i % 3 == 1) { actions.Add(() => y = 10); } } } static void MoreCurlies() { List<Action> actions = new List<Action>(); for (int i = 0; i < 100; i++) { { int x; if (i % 3 == 0) { actions.Add(() => x = 10); } } { int y; if (i % 3 == 1) { actions.Add(() => y = 10); } } } } } 

More curly braces in MoreCurlies look redundant, right? Not really ... the generated code looks something like this:

 using System; using System.Collections.Generic; class Test { static void FewerCurlies() { List<Action> actions = new List<Action>(); for (int i = 0; i < 100; i++) { FewerCurliesCapture capture = new FewerCurliesCapture(); if (i % 3 == 0) { actions.Add(capture.Method1); } if (i % 3 == 1) { actions.Add(capture.Method2); } } } static void MoreCurlies() { List<Action> actions = new List<Action>(); for (int i = 0; i < 100; i++) { { MoreCurliesCapture1 capture = new MoreCurliesCapture1(); if (i % 3 == 0) { actions.Add(capture.Method); } } { MoreCurliesCapture1 capture = new MoreCurliesCapture2(); if (i % 3 == 1) { actions.Add(capture.Method); } } } } private class FewerCurliesCapture { public int x; public int y; public void Method1() { x = 10; } public void Method2() { y = 10; } } private class MoreCurliesCapture1 { public int x; public void Method() { x = 10; } } private class MoreCurliesCapture2 { public int y; public void Method() { y = 10; } } } 

The differences are here:

• A capture class instance is created at each loop iteration in FewerCurlies , even if it is not used.
• Each capture class instance used in FewerCurlies contains both variables, although each delegate actually uses only one of them, while in MoreCurlies each capture class captures only one variable.

It all depends on the particular implementation, but it shows that excess corillets can influence.

Answer 2

As always with such questions, the answer lies in the IL that it generates. For the following code examples:

 public int X() { { { { return 0; } } } } public int Y() { return 0; } 

As a result, we get the following compiled IL:

 .method public hidebysig instance int32 X() cil managed { // Code size 2 (0x2) .maxstack 8 IL_0000: ldc.i4.0 IL_0001: ret } // end of method SomeType::X .method public hidebysig instance int32 Y() cil managed { // Code size 2 (0x2) .maxstack 8 IL_0000: ldc.i4.0 IL_0001: ret } // end of method SomeType::Y 

They are identical. so no, it does not affect performance. X is terrible to read, but this is another problem.

Updating {} affects the amount of variables, so perhaps this can have an effect. Again, check:

 public int X() { var i = 1; { { i++; { return i; } } } } public int Y() { var i = 1; i++; return i; } 

Once again, however, the IL produced is identical:

 // Code size 8 (0x8) .maxstack 2 .locals init ([0] int32 i) IL_0000: ldc.i4.1 IL_0001: stloc.0 IL_0002: ldloc.0 IL_0003: ldc.i4.1 IL_0004: add IL_0005: stloc.0 IL_0006: ldloc.0 IL_0007: ret 

However, if a variable is locked, it affects things. X in the following case creates more IL, which will affect performance:

 public Func<int> X() { { var i = 1; { i++; { return () => i; } } } } public Func<int> Y() { var i = 1; i++; return () => i; } 

Answer 3

The short answer is "no, they do not reduce performance."

The compiler needs curly braces to determine the scope of the variables and know where the current group of statements ends. As soon as the compiler finishes processing, code with unnecessary curly braces and without them will give the same result.

Please note that this is due to the performance of the compiled code, and not to the performance of the compiler itself. The compiler will require additional time to compile the code, simply because the size of the original input is larger. However, in order for this extra time to become measurable, the number of unnecessary braces must be quite extreme.

Answer 4

Unlike C ++, in which the compiler may need to generate code when variables fall into or out of scope, most variables in C # effectively rise to the scope of the function level. The code:

 void foo() { { int i; ... stuff using i as int } { char i; ... stuff using i as char } } 

will effectively turn into:

 void foo() { int i__1; char i__2; ... stuff using i__1 as int ... stuff using i__2 as char } 

with the code from the first bracketed section, using the first i__1 variable, wherever it uses i , and the code in the second, using i__2 . In some cases, it is possible that declaring variables with the same name and purpose in several overview blocks may generate less efficient code than declaring one variable for this common purpose in an external block of visibility, but this would rarely have a significant effect. In most cases, the just-in-time compiler will be able to determine that several variables in the code can be safely mapped to the same storage location, and even in cases where it cannot require storage for several additional variables, it is unlikely to have a very strong effect on performance.

Answer 5

No braces reduce performance.

Something of it is useful in order to raise the code and provide good code formation. But some braces are required, such as the beginning / end of a function, the beginning / end of a loop, the beginning / end of a state, and this line also helps to understand variable variables.

Answer 6

Using unnecessary curly braces, assuming that you do not have nested variables, a label is added to the shortcut table when converting code to bytecode or machine code. In the worst case, assembly time will be slower. If you have variables in nesting, you still shouldn't have problems if they are primitives that don't have a kill code, but if you have objects created in nested braces, then a deeper understanding of GC is required, but I I strongly doubt that any noticeable difference will be present. In all cases, since the compiler does the extra work of storing the links in the lookup table when it creates your project, then there will be a slight delay, although probably invisible to create your project.

Answer 7

This does not mean that there is any performance degradation, but using curly braces definitely improves the readability of your code. In a real-word scenario, when you have peer-to-peer reviews or pair programming, the material you write will be very clear and readable.

Follow the link below

http://www.c-sharpcorner.com/UploadFile/d0e913/lame-question-of-the-day-role-of-curly-braces-in-our-cod/