Hi Michael,Thanks for the info. Yes, there a ways to minimize the overhead and IMHO in practice a naive implementation of this pattern has just too much overhead.
I know at least one real world example, where the memory usage of a software component using this pattern could be reduced by a factor of 10. People sometimes claim that memory is so cheap that this kind of optimizations don't really matter. I don't believe in this, just because if you use 10x more memory per user, your scalability will most likely be limited by the memory usage. Which basically means you will need more machines to serve the same number of users, just because you didn't care that much about memory usage. We had a discussion here about "bloat" lately and my understanding is, that this topic is becoming more important because e4 will support a multi user environment (please correct me if I'm wrong). In such a multi user environment the main concern is the amount of memory you need per user, because as you increase the number of users at some point in time the memory usage will be dominated by the objects that are needed per user. Therefore, if we talk about bloat I think that duplicated code might not be the biggest problem, but rather duplicated data, especially data duplicated per user. IMHO the only approach that can avoid bloat is therefore to carefully design which data can be shared between users and which data needs to be there per user. I think it would make sense to constantly monitor the memory usage using automatic tests. The Eclipse Memory Analyzer could be used for this kind of memory usage tests. Regards, Markus On Wed, Oct 22, 2008 at 8:34 AM, Michael Scharf < [EMAIL PROTECTED]> wrote: > Hi Markus, > > > I once did some calculations for a simple Hashmap implementation versus > > just using instance variables. See my old blog > > at http://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5163 > > interesting post. EMF is something in between. If you use > generated classes (fixed properties), the overhead is 4 > additional object attributes. In case of dynamic EMF you > are much better than using HashMaps, because the attributes > are stored in an array and the key (IStructuralFeature) has > an index into that array (I am sure Ed can give some > numbers here). So, with EMF you have the choice > between dynamic and fixed properties and you can > mix both approaches..... > > Unfortunately EMF is not good at delegating non existing > properties to another instance. Just two weeks ago I > worked with a colleague on an extension of EMF that > allows this (in fact it adds a kind of aspects (AOP) to > EMF that allows interception of the set/get methods). > > > > http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html > > Pretty interesting article but quite long -- I started reading > but after 30 min I decided to "fast read" the rest... > > > Michael > > > Hi all, >> I agree that's an interesting post. But Steve IMHO doesn't point out that >> the main problem with this approach is that it can have a high memory >> overhead. >> I once did some calculations for a simple Hashmap implementation versus >> just using instance variables. See my old blog at >> http://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5163 >> >> Regards, >> Markus >> >> On Mon, Oct 20, 2008 at 5:44 PM, Simon Kaegi <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html >> >> >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> <mailto:[email protected]> >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
