It might seem like a good idea to start from the top, because you need to find the biggest factor, but it is not. The smallest possible factor is 2, therefore the greatest possible factor would be n/2
. You spend the first n/2
, i.e. 300425737571 iterations in vain. It's worse in your case, because the smallest factor is 17.
Don't try to be clever. Start your factorisation from the bottom. When you find a factor, divide your number by it, possibly several times, and store the last factor. Stop when your number is 1.
(This naive method is still bad if your number is, say, the square of a prime, but on average and if you just check one number, it should be reasonably fast.)
Edit: Here's the code that will find the greatest factor in the way I've described above. It will work reasonably fast fon non-primes, but running it on a large prime (479001599) takes about 4 seconds on my machine. The OP's original input was more than 1,000 times as big.
With this caveat out of the way, here goes:
LONG64 max_fact(LONG64 iBigNum)
{
LONG64 maxFact = 1;
LONG64 i = 2;
while(iBigNum > 1)
{
while (iBigNum % i == 0){
iBigNum /= i;
maxFact = i;
}
if (i == 2) i = 3; else i += 2;
}
return maxFact;
}