Profiling results
Jprofiler shows that short of processes going toward filter processing for the Sakai portal, most of the proceessing required to handle a request (to view a topic) is taking place in DiscussionForumTool.getDecoratedTopic(). 40% of the request is processed by portal classes and the rest stack does little with the remaining 60% until this method, (2.5% in FilterChain.doFilter() a javax.servlet package class, and about 3% of the remaining in displayTopicById).
Thus the remaining processing (.6 * .975 * .97 = ~57%) takes place in getDecoratedTopic
Within this method (getDecoratedTopic) almost all the muscle is used in forumManager (service) calls:
- 26% is in getTopicByIdWithMessages
- 26% is in hasPreviousTopic
- 17.3% is in another invocation of hasPreviousTopic
- 15% is in hasNextTopic
- 13.6% is in another invocation of *hasNextTopic *
Both hasNextTopic and hasPreviousTopic are full scans of the forum's topics in their stored order. The scan compares the incoming/supplied topic with each iteration value. Upon a match, hasPrevTopic returns true of the previous iteration value (topic) is not null and hasNextTopic returns true of the next iteration value after the match is not null.
Possible optimizing
hasNext and hasPrevious
- assuming that a given topic is in the forum at all, the result from hasPreviousTopic will always be "true" after the first iteration.
- the result of hasNextTopic will always be"true" unless it is the last topic
getDecoratedTopic
- save the results of previous invocations at the least. This should alone reduce CPU load spent in the pared method by 50% and response times by about %30