[Masterakos]

Hello,

I've created a task to execute in C#. I tried to watch the execution time and i noticed something strange (at least for me). The task is this :

static void Main(string[] args)
        {
        jump: // Task is starting
            Gameboard board = new Gameboard(); //initialize things
            board.Initialize_NewGame(); //initialize things
            ChessEngine engine = new ChessEngine(); //initialize things
            Stopwatch watch = new Stopwatch(); //initialize things

            watch.Start(); // *** Stopwatch Starts ***
            foreach (Piece piece in board.Pieces)
            {
                if (piece.Color == 'W') engine.Generate_Moves(piece, new VitrualGameboard(board.Squares, board.Pieces));
            }
            watch.Stop(); // *** Stopwatch Starts ***

            Console.WriteLine("Moves generated in :" + watch.Elapsed.TotalMilliseconds.ToString("0.00") + " ms total");
            if (Console.ReadLine() == "") goto jump;
        }

So after the watch.Stop() i can print the execution time and IF i press Enter the task starts again and i get more results in milliseconds always.

Now let me show you the results on the image.





So how is this possible? I mean the difference in the first execution is obvious.
Does CPU cache memory has something to do with this ?

[Ryano121]

When you run it first the CLR has to convert the IL into native machine code to run on your machine - this takes time. However when you do it again, the CLR remembers what machine code was generated before so doesn't have to generate it again. This improves the speed on subsequent rounds.

Also goto == bad Nothing wrong with a sentinel while loop though.

This post has been edited by Ryano121: 28 October 2012 - 04:43 AM

[Curtis Rutland]

Agreeing with the goto sentiment. This is essentially the same:

static void Main(string[] args)
{
	do{
		Gameboard board = new Gameboard(); //initialize things
		board.Initialize_NewGame(); //initialize things
		ChessEngine engine = new ChessEngine(); //initialize things
		Stopwatch watch = new Stopwatch(); //initialize things

		watch.Start(); // *** Stopwatch Starts ***
		foreach (Piece piece in board.Pieces)
		{
			if (piece.Color == 'W') engine.Generate_Moves(piece, new VitrualGameboard(board.Squares, board.Pieces));
		}
		watch.Stop(); // *** Stopwatch Starts ***

		Console.WriteLine("Moves generated in :" + watch.Elapsed.TotalMilliseconds.ToString("0.00") + " ms total");
	}while(Console.ReadLine() == "");
}

With the added benefit of not using GOTOs.

[Masterakos]

why using goto == bad ? Very interesting, i've never heard of it.

[Curtis Rutland]

You've been out of the loop...it's been bad since 1968:

http://www.u.arizona...ed_Harmful.html

Here's a slightly more modern discussion:

http://stackoverflow...sidered-harmful

The general consensus is, don't use goto. If you find yourself needing goto, you probably need to reengineer something.

[Momerath]

There was an article published after the 1968 one (which I can't find) pointing out certain program constructs that become confusing without using GOTO.

The question you should ask yourself: If goto is so bad, why did they include it in the C# language?

[Curtis Rutland]

I believe that the reason the designers left goto in was to allow a behavior like falling through in switch statements, since cases are also labels.

The MSDN also lists an example of breaking out of a deeply nested series of if statements. I prefer Java's approach here, using a labeled break statement.

However, I've yet to see a non-trivial example where goto actually simplifies code. One that can't be refactored so that it is still as readable without the goto. Everyone shows the nested ifs, but I say you can change the design to not rely on deep nesting. That's a bad design in the first place.

[lucky3]

I actually used goto recently, and I think it was "justified" (as far as goto can be). I was calculating planets' positions at given time, and was working on procedures from internet source. As Pluto is no longer a planet, calculations for it, wasn't available at that source.

Later I found out that I'd need to calculate Pluto's positions, too. So I've searched for another internet source, and implemented those calculations in the same function, as for other planets. Methods for Pluto, differed, let's say, in the first 1/3 of the procedure.

I could re-factor my original function, and call one method for other planets' calculations, and other for Pluto's, return results to this common function, and continue with the rest 2/3 of this original function with returned data. I could avoid goto here, but I didn't do it, because this would mean just sending the same variables to one or another function, and then retrieve back calculated values, just to use them further. I went with if block for Pluto, using same variables from this common function, and point it with goto to the last 2/3 of the function, skipping first 1/3, where calculations for other planets are done.

For me, at this particular case, using goto was justified, although I share common opinion on not using it.