[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2923) Performance: Events need not be fired for seam-internal context variable manipulation
1:06 p.m.
Performance: Events need not be fired for seam-internal context variable manipulation
-------------------------------------------------------------------------------------
Key: JBSEAM-2923
URL: http://jira.jboss.com/jira/browse/JBSEAM-2923
Project: Seam
Issue Type: Bug
Affects Versions: 2.1.0.A1
Reporter: Clint Popetz
This isn't a "bug" but I wasn't sure what to use for "proposed
performance enhancement."
While profiling, I noticed that the work which ManagedEntityIdentityInterceptor does
results in a lot of [pre|post][Set|Remove]Variable events for the swizzled fields that are
being placed in the conversation context, though those variables aren't documented and
wouldn't therefore have listeners (presumably.) In general, a lot of internal seam
code does things like this, and "Events.instance().raiseEvent" x 2 for each
.set() or .remove() is not trivial, according to my profiling, even when no one is
listening, mainly because each Events.instance() results in a call to
Component.getInstance().
That leads me to believe the Context interface should a form of set() and remove() that
takes a boolean "silent" paremeter, and if it is true, they raise no events.
The old methods call into the new ones with that parameter set to false. Things like
ManagedEntityIdentityInterceptor pass true for efficiency. The idea would be that
set/removes which result from outjections and factories would fire events, but
sets/removes from internal seam manipulations wouldn't. Another example are the five
sets that MethodContextInterceptor does to the method context. That's ten events
fired for no reason on every invocation of a non-entity seam component method.
I have a local patch to do this, and can clean it up and attach it here if the seam
developers feel its an acceptable approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:43 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2923) Performance: Events need not be fired for seam-internal context variable manipulation
[ http://jira.jboss.com/jira/browse/JBSEAM-2923?page=all ]
Pete Muir updated JBSEAM-2923:
------------------------------
Component/s: Performance and Scalability
Performance: Events need not be fired for seam-internal context
variable manipulation
-------------------------------------------------------------------------------------
Key: JBSEAM-2923
URL: http://jira.jboss.com/jira/browse/JBSEAM-2923
Project: Seam
Issue Type: Bug
Components: Performance and Scalability
Affects Versions: 2.1.0.A1
Reporter: Clint Popetz
This isn't a "bug" but I wasn't sure what to use for "proposed
performance enhancement."
While profiling, I noticed that the work which ManagedEntityIdentityInterceptor does
results in a lot of [pre|post][Set|Remove]Variable events for the swizzled fields that are
being placed in the conversation context, though those variables aren't documented and
wouldn't therefore have listeners (presumably.) In general, a lot of internal seam
code does things like this, and "Events.instance().raiseEvent" x 2 for each
.set() or .remove() is not trivial, according to my profiling, even when no one is
listening, mainly because each Events.instance() results in a call to
Component.getInstance().
That leads me to believe the Context interface should a form of set() and remove() that
takes a boolean "silent" paremeter, and if it is true, they raise no events.
The old methods call into the new ones with that parameter set to false. Things like
ManagedEntityIdentityInterceptor pass true for efficiency. The idea would be that
set/removes which result from outjections and factories would fire events, but
sets/removes from internal seam manipulations wouldn't. Another example are the five
sets that MethodContextInterceptor does to the method context. That's ten events
fired for no reason on every invocation of a non-entity seam component method.
I have a local patch to do this, and can clean it up and attach it here if the seam
developers feel its an acceptable approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:46 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2923) Performance: Events need not be fired for seam-internal context variable manipulation
[ http://jira.jboss.com/jira/browse/JBSEAM-2923?page=comments#action_12411647 ]
Guillaume Jeudy commented on JBSEAM-2923:
-----------------------------------------
without looking at seem source code in depth I think your observation makes sense and
would probably explain the numerous debug log entries I see in my logs which leads me to
believe that all this internal seam context variable manipulation is very time
consuming..
Example below:
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.core.Events] Processing
event:org.jboss.seam.preSetVariable.classificationISOAction.coverageGroups
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] instantiating Seam component:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] initializing new instance of:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] done initializing:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] instantiating Seam component:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] initializing new instance of:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] done initializing:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.core.Events] Processing
event:org.jboss.seam.postSetVariable.classificationISOAction.coverageGroups
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] instantiating Seam component:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] initializing new instance of:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] done initializing:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] instantiating Seam component:
org.jboss.seam.core.events
2008-05-02 13:32:59,518 DEBUG [org.jboss.seam.Component] initializing new instance of:
org.jboss.seam.core.events
Performance: Events need not be fired for seam-internal context
variable manipulation
-------------------------------------------------------------------------------------
Key: JBSEAM-2923
URL: http://jira.jboss.com/jira/browse/JBSEAM-2923
Project: Seam
Issue Type: Bug
Components: Performance and Scalability
Affects Versions: 2.1.0.A1
Reporter: Clint Popetz
This isn't a "bug" but I wasn't sure what to use for "proposed
performance enhancement."
While profiling, I noticed that the work which ManagedEntityIdentityInterceptor does
results in a lot of [pre|post][Set|Remove]Variable events for the swizzled fields that are
being placed in the conversation context, though those variables aren't documented and
wouldn't therefore have listeners (presumably.) In general, a lot of internal seam
code does things like this, and "Events.instance().raiseEvent" x 2 for each
.set() or .remove() is not trivial, according to my profiling, even when no one is
listening, mainly because each Events.instance() results in a call to
Component.getInstance().
That leads me to believe the Context interface should a form of set() and remove() that
takes a boolean "silent" paremeter, and if it is true, they raise no events.
The old methods call into the new ones with that parameter set to false. Things like
ManagedEntityIdentityInterceptor pass true for efficiency. The idea would be that
set/removes which result from outjections and factories would fire events, but
sets/removes from internal seam manipulations wouldn't. Another example are the five
sets that MethodContextInterceptor does to the method context. That's ten events
fired for no reason on every invocation of a non-entity seam component method.
I have a local patch to do this, and can clean it up and attach it here if the seam
developers feel its an acceptable approach.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6093
days inactive
6102
days old
2 comments
3 participants
participants (3)
-
Clint Popetz (JIRA) -
Guillaume Jeudy (JIRA)
-
Pete Muir (JIRA)