Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 74473 invoked from network); 14 Mar 2003 17:17:30 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 14 Mar 2003 17:17:30 -0000 Received: (qmail 11558 invoked by uid 97); 14 Mar 2003 17:19:14 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@nagoya.betaversion.org Received: (qmail 11550 invoked from network); 14 Mar 2003 17:19:14 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 14 Mar 2003 17:19:14 -0000 Received: (qmail 74038 invoked by uid 500); 14 Mar 2003 17:17:21 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 73963 invoked from network); 14 Mar 2003 17:17:20 -0000 Received: from www2.mail.lycos.com (HELO mailcity.com) (209.202.220.150) by daedalus.apache.org with SMTP; 14 Mar 2003 17:17:20 -0000 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri, 14 Mar 2003 17:17:05 -0000 To: tatu@hypermall.net, lucene-dev@jakarta.apache.org Date: Fri, 14 Mar 2003 09:17:05 -0800 From: "none none" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: korfut@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: Iterators for collecting Terms from Queries X-Sender-Ip: 64.187.36.2 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N hi Tatu, i didn't really look at all the code, but at a first looks nice, i like the idea, but i have something to say. When we run a search, we collect all the terms already (in a previous email i mentioned something about that, see "rewrite" method), your idea is very elegant from a programming-style point of view, but i believe it slow down performance compared to mine. My idea doesn't add any extra class, or the most it can is just one, a lot of changes are done in the lucene core, so the main difference can be seen as follow: My case 1) set a boolean value inside Query class to true: collectTerms(true); 2) run the search 3) the searcher (reader actually) will call the method "rewrite" or some other methods, inside this method we check if the user want collect the terms testing the public boolean collectTerms. This is to avoid consumption of un-necessary memory by a user that doesn't need to collect the terms. 4) terms are now in memory in different query classes, depends on the "user query", e.g.: a boolean query of 2 multitermquery. so the user can collect them the way he wants and use them. e.g.: i collect them and store in an array of Clauses, someone may just want to put in an array. Your case: 1) run the search 2) the searcher collect all the terms because it needs due to produce rsearch results. 3) use your term collector to collect the terms. ATTN: this will do something that has been done already by the searcher! so, i think it is a waste of resources and time, and as result performance slows down. I want underline that the time to put an object in an array and get it back is still the same, the difference is call the reader twice instead of one. I am not sure how much is the difference between the two cases, but for logic i think there has to be, even more when we dial with prefixquery or rangequery (that's where mainly we need the collector actually!). It may sounds weird, but i lost all the data on my pc, this monday, so i can't compare them, also i have to implement my idea again.. Let me know what you think, Ciao. _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org