lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/LUCENE-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242177#comment-13242177
] 

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: https://issues.apache.org/jira/browse/LUCENE-3935
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message