How much of this profiler patent (US Patent No. 8,516,467) distinguishes over prior art?

Question

A lot of this patent feels like it has prior art in existing tools such as disassemblers and profilers.

Patent text

Claim 1

1. A method for detecting a time complexity associated with an executable program stored in a computer memory device, comprising:

   (1) automatically analyzing said stored program with a computer processor to detect the time complexity of said program based on loops in the code;

   (2) automatically analyzing said stored program with said processor to detect the time complexity of said program based on a code flow and a destination of branching instructions in the program;

   automatically determining the minimum time complexity between the time complexity detected in (1) and the time complexity detected in (2) as the time complexity of said program.

Answer 1

IDA Pro seems to cover claims 2a, 2b, 4 and 5. The profiler in Visual studio seems to cover claim 14 and Visual Studio in general seems to cover most of claim 17 and 18.

Answer 2

The first claim seems to be pretty much what you would want to do in a real-time system where you want to automatically determine whether a given piece of code will fulfill the real-time requirements you have. This would be known as static profiling to determine the worst case execution time (WCET).

One likely prior art reference could be this publication.

I haven't read anything past the abstract, but the abstract may be broad enough to invalidate the first claim alone.

Answer 3

The patent description was very long and I quickly went through it. So I may have misunderstood. But I got the impression that the aim of the patent is to make a performance analysis by code inspection without running the code. Common profilers report the performance by running the code while common code inspectors focus on possible coding mistakes or excessive complexity that hinders maintenance.

If the interpretation is restricted to the above point it might actually be something new, or at least the prior art is not so obvious, but I doubt it would be something useful, most of the time the performance depends on the runtime data. Developers might write some very complex loops because they know that at runtime that function would process very small lists, an automated tool would not be aware of such considerations.