[
https://issues.apache.org/jira/browse/GIRAPH-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570717#comment-13570717
]
Claudio Martella commented on GIRAPH-461:
-----------------------------------------
Ok, I will show that performance does not degrade explicitly (although I'd
claim that these already do). To show that performance is actually improved for
certain algorithms and data partitioning, is out of scope currently, as it
would require to build a particular graph with a particular partitioning, and
that would impact on many different things (e.g. load balancing). I agree that
it would be nice to see it with numbers, and I plan to test this further in the
near future as part of my current research. Lets say we should be happy if this
does not make things worse, as we get the fix to multithreading, and we get a
strategy that can strongly improve performance within certain conditions.
One thing has to be considered though. The other condition for which we could
gain performance wrt to the static assignment is in the other point where we
load the partitions, i.e. when resolving mutations. Again, by considering
vertices distributed uniformly, we should not see a big impact. But we have
acted on a best-effort with LRU.
> Convert static assignment of in-memory partitions with LRU cache
> ----------------------------------------------------------------
>
> Key: GIRAPH-461
> URL: https://issues.apache.org/jira/browse/GIRAPH-461
> Project: Giraph
> Issue Type: Sub-task
> Components: graph
> Reporter: Claudio Martella
> Attachments: GIRAPH-461.patch, GIRAPH-461.patch, GIRAPH-461.patch
>
>
> Currently, the out-of-core partitions are assigned to memory or to disk
> statically. Using an LRU cache should help keeping in-memory only the
> partitions that are actively accessed, given a job that does not access all
> the graph at each superstep (traversals) and a good data partitioning (non
> random).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
