Should MethodContextInterceptor use a non-event triggering c

[kahliburke]

I've been doing some profiling of our application, and finding in some cases that a considerable amount of time per request (> 500 ms) is being taken up by event triggering and handling.

When I look at the main source of the events, they appear to come from the MethodContextInterceptor, which sets variables in the method context (an instance of BasicContext). I can understand the desire for pre and post set/get events, but I'm wondering if they are necessary in this case. The way it is now, each component method call results in 10 events being triggered. When we have a component method that is called repeatedly, such as in a JSF control, this really adds up.

I looked through the Seam source code, and I didn't see anything that relies on preSetVariable/postSetVariable.

My proposal would be a non-event triggering context that does exactly what the BasicContext does, with the exception of the event firing. This could be the superclass to BasicContext.

Any thoughts?

[pmuir]

What percentage of the request time is taken up by events?

Please file a JIRA issue, I can see that this causes a lot of events to be generated.

[kahliburke]

Pete, thanks for the response.

I don't have the profiler results any more, but I believe the page time was around 3-4 seconds. This was a bit of an expensive page due to the amount of data being output in a table form, and that probably also explains why the event notification was becoming noticeable in this situation. I imagine in most cases it wouldn't be a problem.

I'll enter a JIRA issue shortly.

[kahliburke]

http://jira.jboss.org/jira/browse/JBSEAM-2314