Hi Michael, this is fine for me. I would have made a prototype, but since Said is at it, this is perfect. BTW, will your spec also address filtering? I am not sure if AgileGrid does support filtering, so that might have to go into the ContentProvider and will affect the getProrRow logic.
Regards, Andreas Am 07.06.2012 20:27, schrieb Michael Jastram: > 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 -- Andreas Graf Business Development Manager Automotive Spokesperson Eclipse Automotive Industry WG Mobil: +49 (0) 151-10860479 (preferred) Tel.: +49 (0) 711 / 34 21 91-0 Fax.: +49 (0) 711 / 34 21 91-29 Web: http://www.itemis.de Mail: andreas.g...@itemis.de Xing: http://www.xing.com/profile/Andreas_Graf Twitter: http://www.twitter.com/grafandreas Blog: http://5ise.quanxinquanyi.de itemis GmbH Meitnerstr. 10 D-70563 Stuttgart Rechtlicher Hinweis: Amtsgericht Mannheim, HRB 50700996 Ust.Id.Nr.: DE250574762 Geschäftsführer: Sebastian Neus
_______________________________________________ rmf-dev mailing list rmf-dev@eclipse.org http://dev.eclipse.org/mailman/listinfo/rmf-dev
