Re: Worst Case Execution Time Tool?

[Ted Dennison<dennison@telepath.com>]

In article <3C0FE2DE.4BD905B9@computer.org>, StationSteve says...
>
>Ok, do you have time to educate me a little bit?
>Why would a tool have to be "pretty darn smart" to measure the worst-case 
>execution time of a list traversal?  What's the big driver in making such a 
>thing hard to do?

Well, if its a dynamicly allocated list, then theoreticly the "worst case" would
be the amount of time it takes to iterate through n/j items, where n is the
amount of free memory you have after your program loads and j is the amount of
bytes per list item. :-)

In most cases there is a smaller "worst case" available, but you have to know a
fair bit about the system to know what it is. For my real-time scheduler
example, it could be that the list is implemented in an array with a hard limit
of 40 items, and it wouldn't be too horribly dificult for a code analyzer to
figure that out (although not trivial). On the other hand, it could be that the
limit is the number of items listed in a configuration file that is read in at
runtime. There's no possible way a tool could figure that out, because it isn't
really set at all.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.