[MAHOUT-905] CachingUserSimilarity and CachingItemSimilarity have wrong (far to small) default maxSizes - ASF JIRA

XML

Word

Printable

JSON

Details

Type: Improvement
Status: Closed
Priority: Minor
Resolution: Not A Problem
Affects Version/s: 0.5
Fix Version/s: None
Component/s: None
Labels:
- caching
- max
- similarity
Environment:

Hide

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.

Show
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.

Description

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.

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending

CachingSimilariyAdjustedDefaultSize.patch
30/Nov/11 22:13
1 kB
Manuel Blechschmidt

Activity

People

Assignee:: Sean R. Owen

Reporter:: Manuel Blechschmidt

Votes:: 0 Vote for this issue

Watchers:: 0 Start watching this issue

Dates

Created:: 30/Nov/11 22:12

Updated:: 31/Jan/24 22:11

Resolved:: 30/Nov/11 22:19

Time Tracking

Estimated:

0.5h

Remaining:

0.5h

Logged:

Not Specified