Yeah, thats why I felt I needed the joking disclaimer. I'm sure its not
a horrible way to quickly measure. Just surprised to see those specs:)
With so much talk of GC, I'm sure things would vary with the parallel
new space collection, throughput or low pause old space collection, new
space size, server or client jvm, hotspot warmup etc etc etc.
Even a multiprocessor multicore bench isnt going to be something that
can't be uselessly attacked :)
Yonik Seeley wrote:
On Sun, Nov 2, 2008 at 4:43 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
Single processor pentium 4? Shouldn't someone benchmark this with tech from
this century:) you know some comps are not room size now right?
:-P
I'm not sure the benchmarks are good enough to draw any useful
conclusions, other than FastLRUCache is always a win (even single
threaded) when the hit rate of the cache is high (and that's why I've
only switched the default on the filter cache).
The queryCache and documentCache typically have lower hit rates - but
I think someone will need to try out both with Solr (not a
micro-benchmark) to tell if it will be a net win for those.
-Yonik
Not being very serious...
- Mark
On Nov 2, 2008, at 10:34 AM, "Yonik Seeley (JIRA)" <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644594#action_12644594
]
Yonik Seeley commented on SOLR-667:
-----------------------------------
bq. Isn't it too expensive to create a potentially huge array every time
we do a clean? (too much work for GC)
That's what benchmarking is for :-)
It's a single short-lived allocation that allows us to greatly reduce the
number of elements we need to evaluate on successive passes. Inserts into a
TreeSet may have a higher GC cost given it's an allocation per insert.
Alternate LRUCache implementation
---------------------------------
Key: SOLR-667
URL: https://issues.apache.org/jira/browse/SOLR-667
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Yonik Seeley
Fix For: 1.4
Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
ConcurrentLRUCache.java, SOLR-667-alternate.patch, SOLR-667-alternate.patch,
SOLR-667-updates.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
SOLR-667.patch, SOLR-667.patch
The only available SolrCache i.e LRUCache is based on _LinkedHashMap_
which has _get()_ also synchronized. This can cause severe bottlenecks for
faceted search. Any alternate implementation which can be faster/better must
be considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
