lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Moen (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3935) Optimize Kuromoji inner loop - rewrite ConnectionCosts.get() method
Date Fri, 30 Mar 2012 09:14:37 GMT


Christian Moen commented on LUCENE-3935:

Thanks, Mike, Uwe and Dawid.

It's a good idea to do testing using {{int}} -- thanks for that.  I did this hastily last
night and results suggested that there wasn't a lot to be gained on Mac OS X, but I will look
more into this and do a better test.

Kuromoji has a low memory footprint (uses FST instead of double-array trie, does Viterbi in
a streaming fashion, etc.), which is a nice characteristic I'd like to keep.  Hence, I'm reluctant
to trade 3MB of memory unless {{int}} really gives us a lot in terms of additional speed.
 (Kuromoji currently segments ~2.5-3MB/sec per CPU core on my system.)

I'll do some additional testing, have a think, but I'm likely to commit the {{short}} version
in the attached patch tomorrow.
> Optimize Kuromoji inner loop - rewrite ConnectionCosts.get() method
> -------------------------------------------------------------------
>                 Key: LUCENE-3935
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: modules/analysis
>    Affects Versions: 3.6, 4.0
>            Reporter: Christian Moen
>         Attachments: LUCENE-3935.patch
> I've been profiling Kuromoji, and not very surprisingly, method {{ConnectionCosts.get(int
forwardId, int backwardId)}} that looks up costs in the Viterbi is called many many times
and contributes to more processing time than I had expected.
> This method is currently backed by a {{short[][]}}.  This data stored here structure
is a two dimensional array with both dimensions being fixed with 1316 elements in each dimension.
 (The data is {{matrix.def}} in MeCab-IPADIC.)
> We can rewrite this to use a single one-dimensional array instead, and we will at least
save one bounds check, a pointer reference, and we should also get much better cache utilization
since this structure is likely to be in very local CPU cache.
> I think this will be a nice optimization.  Working on it... 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message