I have written a program to calculate the number of stable partition in a graph. ( That is: find which partition of the nodes does not have edges between nodes of the same block. )
The professor, asked me a way to evaluate the performance of my algorithm (not the program), but my algorithm is simply a brute force of all the possible cases, and I don't think you can do any better without heuristics, therefore I think the questions makes no sense (at least to me).
Am I wrong?
It doesn't matter for what the algorithm is for, that is, you can analyze an algorithm for an easy problem (e.g. sorting) just like you would analyze an algorithm for a hard problem (e.g. 3-SAT). So the question does make sense.
Think about how your brute force method works. If you try all partitions of nodes, how many possible partitions are there? This is the way your analysis should work. Given that the problem is NP-hard, one should not expect a polynomial time algorithm though, but that's fine.
There are plenty of ways to go about dealing with NP-hard problems.
Even if you know the asymptotic upper bounds on worst-case runtime (more you usually don't get), you don't have information about
In the absence of exact analyses, all you can do is run the algorithm on a representative sample of inputs and compare it to others.
To be clear, even though your algorithm has bad $O$-runtime (in the worst case) it does not always take this long to finish. Go find out!
Conducting meaningful runtime experiments is not trivial, and often done horribly wrong in the literature. I can recommend (the affordable) A Guide to Experimental Algorithmics by C.C. McGeoch (2012) for an introduction.
Maybe your professor is asking you to implement and run your algorithm and evaluate the time it takes in different sizes of instances. As is brute force, maybe you can't go away to more than 20 vertices, but is still a good excercise.
