lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Commented: (LUCENE-937) Make CachingTokenFilter faster
Date Fri, 22 Jun 2007 02:20:25 GMT


Mark Miller commented on LUCENE-937:

> So it may be safe to say that if you can estimate the list size (avoiding array grow),
AL is preferable if there's no add/remove not at the end.

In the CachingTokenFilter case I don't even believe it is really necessary to estimate the
list size. Many of the documents I used had way more than 30 tokens, but initializing the
Array larger gave no benefits. I believe this is because the ArrayList doubles each time it
grows (not guaranteed, but how it is implemented), and so a small increase in size can dramatically
lower the number of resizes needed even when the List must grow *much* bigger than the init
size. 10 just doesn't cut it, but 30 works great. A LinkedList (iterator or get()) seems to
perform no better than an ArrayList(10).

- Mark

> Make CachingTokenFilter faster
> ------------------------------
>                 Key: LUCENE-937
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Priority: Minor
>         Attachments: CachingTokenFilter.patch
> The wrong data structure was used for the CachingTokenFilter. It should be an ArrayList
rather than a LinkedList. There is a noticeable difference in speed.

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:
For additional commands, e-mail:

View raw message