[
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: [email protected]
For additional commands, e-mail: [email protected]
