乘法比求和快吗？

Question

Consider this ( Project Euler Problem 714 ):

We call a natural number a duodigit if its decimal representation uses no more than two different digits. For example, 12, 110 and 33333 are duodigits, while 102 is not. It can be shown that every natural number has duodigit multiples. Let d(n) be the smallest (positive) multiple of the number n that happens to be a duodigit. For example, d(12)=12, d(102)=1122, d(103)=515, d(290)=11011010 and d(317)=211122.

I check if number is duodigit by converting it to string and then get the number of characters in a HashSet<char> ( HashSet is a collection that contains no duplicate elements) of the string.

I have two ways to get the duodigit multiple of the number, if the number is not duodigit itself.

Consider int x = 0; .

The first way is to keep adding the number to x until x become a duodigit.

The second way is to keep adding 1 to x until x * number become a duodigit.

I used System.Diagnostics.Stopwatch to see which is faster and I got this result:

First way: 8 milliseconds
Second way: 0 milliseconds

My question is "Why the second way is faster?". I thought maybe multiplication is faster than summation in this case (Is it?).

Here's the code:

using System;
using System.Collections.Generic;
using System.Diagnostics;

namespace ConsoleApp4
{
    class Program
    {
        static void Main(string[] args)
        {
            int number = 12345;

            // First way:
            Stopwatch a = new Stopwatch();
            a.Start();
            int x = number;

            while (new HashSet<char>(x.ToString()).Count > 2)
                x += number;

            a.Stop();


            // Second way:
            Stopwatch b = new Stopwatch();
            b.Start();
            int y = 1;

            while (new HashSet<char>((number * y).ToString()).Count > 2)
                y++;

            b.Stop();

            Console.WriteLine("First way: {0} milliseconds", a.ElapsedMilliseconds);
            Console.WriteLine("Second way: {0} milliseconds", b.ElapsedMilliseconds);
        }
    }
}

And I have tried many times and after warming up but I got the same result each time.

But I got the same results when I tried first and second way separately:

int number = 12345;

// First way:
Stopwatch a = new Stopwatch();
a.Start();
int x = number;

while (new HashSet<char>(x.ToString()).Count > 2)
    x += number;

a.Stop();

Console.WriteLine("First way: {0} milliseconds", a.ElapsedMilliseconds);

// Output:
// First way: 7 milliseconds

int number = 12345;

// Second way:
Stopwatch b = new Stopwatch();
b.Start();
int y = 1;

while (new HashSet<char>((number * y).ToString()).Count > 2)
    y++;

b.Stop();

Console.WriteLine("Second way: {0} milliseconds", b.ElapsedMilliseconds);

// Output:
// Second way: 8 milliseconds

Answer 1

The thing that is going on here is that you are measuring compiler overhead. The jitter will compile a method the first time it is run, so the first time any code is run the time will be slightly slower. Benchmarking need to take this into consideration, and tools like Benchmarking.Net does this for you.

A quick and dirty trick is to loop whatever operation is run to ensure it runs for a few seconds, this will reduce the effect of the compiler overhead. Repeating your example a million times produces the times:

First way: 9627 milliseconds
Second way: 9549 milliseconds

Ie Within measurement errors for this rudimentary method.

Multiplication should be slightly slower than addition, but both are some of the fastest instructions you can do. The other things in your example, like converting a number to a string or creating a hashSet will utterly dwarf any differnce between addition vs multiplication.