如何估算使用递归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)).

Eg 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 eg n=5, eg 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.