[jira] [Commented] (MAHOUT-1385) Caching Encoders don't cache

["Johannes Schulte (JIRA)" <ji...@apache.org>]

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

Johannes Schulte commented on MAHOUT-1385:
------------------------------------------

Hi Manjo.

My point was that these classes are (hopefully) meant to be a performance improvement, which would be the case if the string's hashcode could be reused (because the java string object caches it's own hash code).

Using the byte[] hash code is evil because it depends on the reference
Using another library / hashing strategy for the values inside the byte array is nonsense because this is what we are trying to cache if i understand the will of the creator correctly.

The more I think about it - was this ever correct? Using the string hash code as a lookup to the murmurHash-based location? There will be different collisions leading to other results than with no caching, which should be avoided?

> Caching Encoders don't cache
> ----------------------------
>
>                 Key: MAHOUT-1385
>                 URL: https://issues.apache.org/jira/browse/MAHOUT-1385
>             Project: Mahout
>          Issue Type: Bug
>    Affects Versions: 0.8
>            Reporter: Johannes Schulte
>            Priority: Minor
>         Attachments: MAHOUT-1385-test.patch, MAHOUT-1385.patch
>
>
> The Caching... line of encoders contains code of caching the hash code terms added to the vector. However, the method "hashForProbe" inside this classes is never called as the signature has String for the parameter original form (instead of byte[] like other encoders).
> Changing this to byte[] however would lose the java String internal caching of the Strings hash code , that is used as a key in the cache map, triggering another hash code calculation.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)