First execution after compiling incredibly slow, unless it's "obvious" that all loops will halt

Question

What I meant with this title is that for some cases, after building the entire program, its first execution will take about 25 seconds to start (until the first printf shows on the console). The next executions start nearly instantaneously (as they should). Add/remove a space and compile again, and the first execution after is once again excruciatingly slow.

Weather I run it from within the IDE (Code::Blocks) or from the file explorer changes nothing.

But here's what "solves" the problem:

The program I wrote has a cycle and it's constantly waiting for user input:

#include <stdio.h>
#include <string>

using namespace std;

int main()
{
    printf("Welcome!\n");

    bool Running=true;

    do{

      char input[256], command[64];


      if(fgets(input, 256, stdin) == NULL || input[0]=='\n')
        continue;

      sscanf(input, "%s", command);

      string command_cppstr(command);

      if(command_cppstr == "help")
      {
        printf("\n");
        printf("help - displays this list\n");
        printf("exit / quit - exits this progam\n\n");
        continue;
      }
      if(command_cppstr == "exit" || command_cppstr == "quit")
      {
        Running = false;
        continue;
      }

      printf("Unrecognized command. Use command \"help\" for a list of commands and their descriptions.\n");

    }while(Running);

    return 0;
}

This program has the issues mentioned before. But if I do any of a number of things that guarantee that the program will halt, the problem no longer occurs. For example, declaring this:

int i=0;

and inserting the following inside the do while loop:

i++;
if(i>4)
  Running=false;

not only makes the program stop after 4 commands have been processed, it also "solves" the problem - the .exe no longer takes an eternity to execute the first time. I put "solves" between inverted commas because I only wanted my program to halt when the user says so by typing the command "quit" or "exit".

I once again note that I compile first, wait until everything is compiled, and only then do I run the executable.

I would like to know how do I avoid this, because even though I have found a partial solution, it's not exactly ideal to me. I would also like to know what causes this problem. It's as if the computer was reluctant in running code that may never halt, fearing being caught in an endless loop xD.

Thank you for your attention to this post, and thank you in advance to anyone who attempts to answer these questions.

---

Edit:

Ok, here's what I tried so far, after reading the answers:

• Disable Kaspersky (my antivirus) - the issue is gone. But this is not a good solution since I don't like the idea of not having an antivirus.

I reactivated Kaspersky:

• Uncheck "use heuristic analysis do determine [restrictions] group for unknown apps - no effect
• Disable Kaspersky's "App control" - no effect
• Disable Kaspersky's "System Monitorization" - no effect
• Disable Kaspersky's "Antiviros de MI" (Seems to be chat-room related stuff) - no effect
• Disable "Scope of verification" in "vulnerability verification setup" - no effect
• Give the program trustworthy status in Kaspersky's app control - no effect
• Put the program on Kaspersky's Kaspersky excluded list - no effect
• Put code::blocks on Kaspersky's Kaspersky excluded list- no effect

There are a lot of things that can be disabled in Kaspersky, but I think the ones I tried are the most likely to affect this situation. But it must be Kaspersky's fault, since disabling it solved the problem. I guess I'll try disabling more things...

I also tried the following:

• Swap i++ with function declared by me (i passed by reference and increment) - No waiting
• Swap i++ with function declared by me (function returns argument+1) - No waiting
• i starts at 1, is multiplied by 2 at each loop. When it's larger than 8, Running=false - no waiting
• i starts at 0, is multiplied by 2 at each loop. When it's larger than 8, Running=false - waiting (as this doesn't guarantee there will be halting xD)

I will continue to try to change the way i is increased to try to further throw off whatever thing appears to be checking if my program halts or not xD... I will edit this with the results as I make the experiments.

---

I continued trying to find what I could do in Kaspersky that would solve this problem

Apparently, disabling the firewall and the "App control" features solves the problem. But it's not a very good deal to have the computer running without a firewall, I thought.

So I re-enabled both of these functions, and in "App control" there's an option for "unknown apps", between

• Use an heuristic analysis to determine group (i.e. it's "trustworthiness")´
• Automatically put the app to the following group: [box where you can choose between 3 trustworthiness groups]

and then there's a box that says:

maximum time to determine group: <_> seconds.

Now here's the interesting part: The amount of seconds in this box is directly related to the time it takes before a program starts running. (this time is never greater than the amount of seconds + ~2)

But the mystery is not over:

This last line gets grayed out, and the test box gets disabled when I deactivate the heuristic analysis thing, which would suggest that when heuristic analysis is disabled, there would be no waiting. But there is! And it's still related to the time that is inserted to the now un-editable text box!

Oh, and why would the state of the firewall matter at all? Supposedly, deactivating "app control" would be all took for this problem to go away, but no, both the firewall and the app control have to be disabled!

Answer 1

At first sight this looks like antivirus software. Every time it sees a new executable file being run, it checks the file for viruses. Whenever you recompile, it has to check the file again, because it's changed.

But your "solution" to the problem has me baffled! What you describe seems impossible. How can the program (or the OS, or the antivirus software) know that the number of loops is limited? I think further experimentation is in order here.

As a start, you might try adding the executable file to your antivirus software's exclude list. What happens?

Answer 2

Though this is not THE answer to your question but would definetly guide you into

1. Download procmon
2. Add your process name in the filter list (Image name starts with ...)
3. Run three instances of your program along with procmon. Save the trace after each run
   1. The first execution without halting condition
   2. The subsequent execution
   3. Execution with halting condition
4. Compare the resultant trace

Note May be you will solve the Halting Problem