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
_______________________________________________
rmf-dev mailing list
rmf-dev@xxxxxxxxxxx
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.graf@xxxxxxxxx
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
|
