[
https://issues.apache.org/jira/browse/MAHOUT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895891#action_12895891
]
Jake Mannix commented on MAHOUT-456:
------------------------------------
In this case, the code without the clone is certainly slower, because it
requires many inserts into the OrderedIntDoubleMapping (O(n) inserts).
If clone is in fact slow, then the right thing, I guess, is to add a copy
constructor to OrderedIntDoubleMapping, which just allocates the inner int[]
and double[] arrays and System.arraycopy()'s them over.
We do rely on clone() in a variety of places, where is it primarily thought to
be most slow?
Looking more closely at that thread, wasn't the final conclusion this:
{quote}
Posted Date : 2006-09-22 18:58:41.0
Now that
6428387: array clone() much slower than Arrays.copyOf
has been fixed, all methods of copying arrays are equally performant,
so there is no reason to uglify the code for performance.
Closing as Not a Defect.
Posted Date : 2007-06-03 08:30:25.0
{quote}
> RowSimilarityJob should not produce SequentialAccessSparseVectors
> -----------------------------------------------------------------
>
> Key: MAHOUT-456
> URL: https://issues.apache.org/jira/browse/MAHOUT-456
> Project: Mahout
> Issue Type: Improvement
> Components: Math
> Reporter: Sebastian Schelter
> Attachments: MAHOUT-456-2.patch, MAHOUT-456.patch, MAHOUT-456.patch,
> MAHOUT-456.patch
>
>
> RowSimilarityJob currently produces SequentialAccessSparseVectors with
> cardinality Integer.MAX_VALUE wrapped inside VectorWritables.
> It should better produce RandomAccessSparseVectors as some methods like
> assign(Vector) are very slow on such SequentialAccessSparseVectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
