Resolution: Not A Problem
Affects Version/s: 0.5
Fix Version/s: None
Component/s: Collaborative Filtering
Mac OS X 10.6.8
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
This does not matter should be reproducible on every system.ShowMac OS X 10.6.8 java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) This does not matter should be reproducible on every system.
I am currently tuning my recommender discussed here: http://thread.gmane.org/gmane.comp.apache.mahout.user/10433.
As a first step I wrapped my LogLikelihoodSimilarity with an CachingUserSimilarity. I used Java Visual VM to profile the calls. I recognized that I didn't get any performance benefits. So I had a look into the code.
Actually line 47 this(similarity, dataModel.getNumItems()); in CachingUserSimilarity.java is wrong. If we want to cache all item similarities we need a cache with (dataModel.getNumItems()*(dataModel.getNumItems()-1))/2 possible entries.
I am now doing this in the constructor. I attached a patch to adjust this in the trunk build.
|Status||Open [ 1 ]||Patch Available [ 10002 ]|
|Issue Type||Bug [ 1 ]||Improvement [ 4 ]|
|Priority||Major [ 3 ]||Minor [ 4 ]|
|Status||Patch Available [ 10002 ]||Resolved [ 5 ]|
|Resolution||Not A Problem [ 8 ]|
|Status||Resolved [ 5 ]||Closed [ 6 ]|
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|1m 35s||1||Manuel Blechschmidt||30/Nov/11 22:13|
|5m 16s||1||Sean Owen||30/Nov/11 22:19|
|70d 15h 43m||1||Sean Owen||09/Feb/12 14:02|