How to estimate the time and memory consumption of a program that uses recursion Java

Question

I'm solving a Knight's tour problem. The size of a desk is 5X5, and starting point for a tour can be any square. I found all possible open solutions, and calculated the memory usage as well as time consumption of a program. I'm using recursion and on each knight' move I'm calculating the next possible moves for a knight.

The questions is how to calculate memory and time consumption on a much larger desk. What kind of tools are usually used in Java to estimate these values for programs that are impossible to actually run? Should it be just assumption using O-notation?

Answer 1

There are no Java Tools or Tools in other programming languages to do this in General. It is related to the Turing halting problem, which is known to be unsolveable in common.

For your concrete Problem instance you could write one, that tries to extrapolate from your measurments with smaller size boards using a theoretical analysis of the concrete algorithm (O-Notation)).

E.g. if you know, that runtime is O(2^n), which means

t = c * (2 ^ n) ( + neglectable parts)

you can compute the constant c by setting in the equation the concrete time for e.g. n=5, e.g. if you measure t=10s for n=5:

10s = c * (2 ^ 5)

==> c = 10 s / (2 ^ 5)

This is only an example (I dont know if your Problem is O(2 ^n)).

But as I said, for this you have to know the O-Notation of the algorithm, which comes from proofs found by human mathematical intuition, and which is not computable in General by a god-algorithm.

Answer 2

What is the scale-up to your much larger desk?

Please note that there can be a significant difference between calculated consumption (of both time and memory) and the consumption estimated from the complexity. The previous answer (Thomas Philipp) is correct except for one detail:

t = c * (2 ^ n) ( + neglectable parts)

From one theoretical standpoint, this is a contradiction: if you care about the factor c, you also may care about the so-called "neglectable parts". Those drop out in a complexity determination, the O(2^N) world, where the only term that counts is the one that dominates the limit at +infinity.

In practical terms, check your set-up complexity and any looming secondary terms in your algorithm. For instance, one program I worked on had a straightforward O(n^2 log n) solution. There was O(n log n) pre-work and some O(n) overhead.

The problem we faced was that, to our consumers, the algorithm didn't appear to scale that way. For a small task, the overhead dominated. For a typical evaluation task, the pre-work and main body were of roughly equal time. For a true application, the main body showed its true colours and took over, although the first two stages then took longer than an eval task's entire run.

In short, the medium-term computations did not scale as an external viewer would expect, because of the high constant and coefficient values in the lower-complexity stages.