[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845199#action_12845199
]
Michael Busch commented on LUCENE-2324:
---------------------------------------
Here is an interesting article about allocation/deallocation on modern JVMs:
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
And here is a snippet that mentions how pooling is generally not faster anymore:
----
Allocation in JVMs was not always so fast -- early JVMs indeed had poor
allocation and garbage collection performance, which is almost certainly where
this myth got started. In the very early days, we saw a lot of "allocation is
slow" advice -- because it was, along with everything else in early JVMs -- and
performance gurus advocated various tricks to avoid allocation, such as object
pooling. (Public service announcement: Object pooling is now a serious
performance loss for all but the most heavyweight of objects, and even then it
is tricky to get right without introducing concurrency bottlenecks.) However, a
lot has happened since the JDK 1.0 days; the introduction of generational
collectors in JDK 1.2 has enabled a much simpler approach to allocation,
greatly improving performance.
----
> Per thread DocumentsWriters that write their own private segments
> -----------------------------------------------------------------
>
> Key: LUCENE-2324
> URL: https://issues.apache.org/jira/browse/LUCENE-2324
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Michael Busch
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 3.1
>
>
> See LUCENE-2293 for motivation and more details.
> I'm copying here Mike's summary he posted on 2293:
> Change the approach for how we buffer in RAM to a more isolated
> approach, whereby IW has N fully independent RAM segments
> in-process and when a doc needs to be indexed it's added to one of
> them. Each segment would also write its own doc stores and
> "normal" segment merging (not the inefficient merge we now do on
> flush) would merge them. This should be a good simplification in
> the chain (eg maybe we can remove the *PerThread classes). The
> segments can flush independently, letting us make much better
> concurrent use of IO & CPU.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
