[
https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500656
]
Alexander Klimetschek commented on COCOON-2071:
-----------------------------------------------
If I understand you right, the thread-safe stuff only applies to components
that are pooled. If yes, I see no problem with that if pooling is generally
turned off. Or is the proxy needed for non-pooled components as well?
> Option to turn off pooling for components (probably faster on new JVMs and
> simpler debugging)
> ---------------------------------------------------------------------------------------------
>
> Key: COCOON-2071
> URL: https://issues.apache.org/jira/browse/COCOON-2071
> Project: Cocoon
> Issue Type: Test
> Components: - Components: Sitemap
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Alexander Klimetschek
> Assignee: Carsten Ziegeler
> Priority: Minor
> Attachments: disable-pooling-config.patch
>
>
> This is a patch that makes the pooling of components/beans optional: by
> setting this in the applicationContext.xml
> <!-- Activate Avalon Bridge -->
> <avalon:bridge pooling="false"/>
> it is possible to turn off pooling completely. The idea is to start testing
> performance differences between pooling and non-pooling. The default value
> for the "pooling" option is true, so existing configurations without the
> attribute set will behave as before when this patch is applied.
> Pooling was introduced back then when creating a new object in Java was slow
> and re-using of existing objects was faster. Since Java 1.4 this is no longer
> the case, creating new objects is said to be even faster than malloc() in C.
> Because pooling needs a recycle() method (to reset internal stuff before
> reuse) and more calls, including some AOP and Proxy class stuff to add
> pooling, it is worth to check what is faster nowadays.
> One thing that always annoys me during debugging is that the AOP stuff adds
> like 4-5 additional calls when accessing a pooled component in the stacktrace
> - code that you cannot step into, because it has no java source. Removing
> pooling completely would make the Cocoon architecture (especially the runtime
> architecture) much simpler.
> My idea is that Cocoon users can test the performance difference on their
> various systems to get actual results. WDYT?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
