Use or not block definition in simple "if" influences application performance?

2

Some questions arise that do not change the flow of decisions, but may influence application performance by the amount of extra lines depending on how you program.

I like to keep my code as lean as possible, but when it comes to keeping organized, I do not skip lines of code.

In this eagerness to keep a code readable I usually always open and close a block of commands as in the example below:

if (a = b) then
begin
  ShowMessage('A é igual a B');
end;

Please note that there is only one line inside if , but I always like to open begin and end , because if tomorrow you have to insert more rows the block is already ready and I do not have to stay looking for end of if , I do this even if they are nested of if s simple, example:

if (a = b) then
begin
  ShowMessage('A é igual a B');
end 
else 
begin
  if (a = c) then
  begin
    ShowMessage('A é igual a C');
  end;
end;

I could reduce the number of rows of these if s, but I "like" this way of working.

Now the theme question:

  

The use of more rows as in the examples above, does it influence the performance of the application?

     
  • I imagine that the more lines independent of anything the processor and memory will work a bit more, right?
  •   
  • Or is the compiler smart enough to ignore begins when it comes to a simple if ?
  •   

This question came to me from the question of the application already being with thousands and thousands of lines of code, now as quoted, I do not know and these thousands are only lines considered valid by the compiler for running the application or if all lines within the executable.

Another example, but now with "comments"

// Esse bloco de comentário será ignorado pelo compilador?
// Não
// Importa
// Quantas
// Linhas
// Tenha?  
if (a = b) then
  ShowMessage('A é igual a B');

The number of rows above is greater than if simple with begin and end , but I imagine that the compiler treats differently than a command block, because even though the processor has to read the line for know what it's all about.

An example I particularly detest, but it can be more efficient:

if (a = b) then
  ShowMessage('A é igual a B')
else if (a = c) then
  ShowMessage('A é igual a C');

Maybe this can be a pointless discussion, but on a daily basis as the application grows we realize that the performance falls a little bit with each new Form, so any change in the programming habit that contributes to improve this performance can be valid.

Note: I give Delphi (Pascal) an example, but it is valid for any language.

    
asked by anonymous 27.07.2018 / 14:28

1 answer

3
  

Will the use of more rows as in the examples above influence the performance of the application?

In Delphi it does not influence anything in this case reported. Of course, poorly written source code can end up generating a target code that wastes resources. But not by comment or by block start and end indicator that is purely syntactic.

  

I imagine that the more lines independent of anything the processor and memory will work a little longer, right?

Not in compiled language, except at compile time, it will still be tiny. In interpreted language has a cost because compilation occurs at runtime and therefore the interpreter has to work harder during execution . But usually the cost is very small and changes almost nothing in the actual execution of the code. See Reviews weigh? .

  

Or is the compiler smart enough to ignore them when it comes to a simple IF?

It's not about being smart, it's his job. The compiler interprets a text written by a human and generates a code that the machine understands. For the machine there is only really useful code, there are no syntactic things that only serve to help a human organize your code.

It would be interesting to understand what a compiler does . Probably also What is a programming language, IDE, and compiler? .

Coding style each has its own. Too long code tends to be harder to read. Code too squeezed too. This is an art. I've changed my style a few times, and I think every time I'm in the right style, of course. It takes experience to understand the "best" way. The last code is my favorite. In fact I would do everything in one line, at least in another language.

    
27.07.2018 / 15:42