Return to Answer

Final observations

Scanning the length of the numbers in the Fibonacci sequence, roughly every 5 numbers another decimal digit (power of 10) is required. This is corroborated by the approximate quotient of the 300th FibNo requiring 64 digits (~1/5).

From this, one can estimate that the millionth FibNo would require something more than 200,000 decimal digits to express.

Based on this, and an approximation of 3.5 bits to express each decimal digit of a large number, those approx. 200,000 decimal digits would require each BigInteger (a and b and next) to eventually store and process something like 100,000 bytes for each operation (summing or copying).

It can be safely presumed, too, that the BigInteger support grows its allocated storage to meet requirements (multiple calls to realloc()?).

In short, this feels like a frivolous expenditure of machine cycles for questionable purposes. Who would ever seek to print the entire ~200,000 digits of the millionth Fibonacci number?!

EDIT: the 64 digit number checks out with this OEIS list, except that I have used counting numbers to call it the 300th. The list has this FibNo at position 299 (zero based).

The simple code will run pairs of computations.
Each iteration leaves the result in the variable b.
If n is even we seed a and b with 0, 1.
If n is odd the seeds are 1, 1.
If n is odd reduce n by 1 as the starting seeds (1,1) already represent the first iteration's result. Further reduce n by 2 (for those first two sees) and jump in (with pseudo code)...

I've a pet project utilising BCD addition (vastly simplifying the reporting of massive decimal values.) Coding it to fill 64 decimal digits reveals that the 300th Fibonacci number to be:
137347080577163115432025771710279131845700275212767467264610201 There's room for a few more iterations before I'd need to use 65 decimal digits.

The simple code will run pairs of computations.
Each iteration leaves the result in the variable b.
If n is even we seed a and b with 0, 1.
If n is odd the seeds are 1, 1.
If n is odd reduce n by 1 as the starting seeds (1,1) already represent the first iteration's result. Further reduce n by 2 (for those first two seeds) and jump in (with pseudo code)...

I've a pet project utilising BCD addition (vastly simplifying the reporting of massive decimal values.) Coding it to fill 64 decimal digits reveals that the 300th Fibonacci number to be:
137347080577163115432025771710279131845700275212767467264610201 
There's room for a few more iterations before I'd need to use 65 decimal digits.