Hi Andreas, Yes, what you found is what we have right now. This is still the original implementation that was put together quickly to see whether AgileGrid was worth pursuing in the first place.
Actually, an even better implementation approach (then the one you proposed) would be to react to the EMF notifications and update the cache according to those (rather than just evicting the cache). I am currently supervising Said, a student, who is working on the content provider as part of his study requirements. The ContentProvider is a very nice student project, as it is well defined and has a clean interface. Before starting to work on the content provider, I requested from Said to write a suite of unit tests against the current implementation. Before implementing a better content provider, we plan on creating a little spec that we plan on posting here. So unless there is urgency, I would propose to leave this to Said. @Andreas, do you have a deadline for better performance? @Said, what is your estimate of completion? Best, - Michael On 06/07/2012 04:52 PM, Andreas Graf wrote: > Dear all, > > in one of the issues in Bugzilla we have some bug entry for large > models. I just had a look at some code and would like to see if what I > found is correct: > > * The ContentProvider provides data by getProrRow(int) > * This in turn calls recurseSpecHierarchyForRow(n), which traverses the > entire model from beginning until it finds row n. > > That would mean, if a call for getProrRow(999) is followed gy a > getProrRow(1000), the entire model is traversed twice, summing up to > 1999 elements being > visited? So it is quadratic to the number of SpecHierarchies? > > We could not simply cache the data, since the model might change between > to calls of getProrRow(....). However, I was thinking of a helper class > in Xtext, > "OnChangeEvictingCache", which introduces a cache that is attached to an > EMF Resource and automatically cleared when that resource changed. > In addition, the algorithm could be updated a little bit so that , if > the resource did not change, it will continue where it left. > > Any objections or other design ideas? > > Andreas > -- *Michael Jastram* +49 (162) 274 83 94 http://jastram.de Geschäftsführer Formal Mind GmbH http://formalmind.com Wissenschaftler Heinrich Heine Universität Düsseldorf http://www.stups.uni-duesseldorf.de <http://www.stups.uni-duesseldorf.de/w/Michael_Jastram> Vorsitzender rheinjug e.V. http://rheinjug.de Project Lead Eclipse Requirements Modeling Framework http://eclipse.org/rmf
_______________________________________________ rmf-dev mailing list rmf-dev@eclipse.org http://dev.eclipse.org/mailman/listinfo/rmf-dev
