Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epsilon-dev] IPropertyGetters/Setters in Models

This turned out to be a classic case of premature optimisation. I assumed that because some models were caching this, it would be the right thing to do, and when I changed it all tests were passing. However I had missed the PropertySetter in EmfModel, and when I changed this two tests failed and I realised there is state involved. I’ll carefully look at this and revert the changes, and see if there is a better way.


From: Sina Madani
Sent: 27 April 2020 11:01
To: Epislon Project developer discussions
Subject: RE: Re: [epsilon-dev] IPropertyGetters/Setters in Models


Hi Dimitris,


Thank you for the clarification. It appears this was mainly an issue in JavaModel, PlainXmlModel, XmlModel and AbstractEmfModel. The others were all using a propertyGetter/propertySetter field, so I have moved this to the Model class and updated extensions accordingly so that the appropriate type is assigned in the constructor.





From: Dimitris Kolovos
Sent: 27 April 2020 08:30
To: Epislon Project developer discussions
Subject: Re: [epsilon-dev] IPropertyGetters/Setters in Models


Hi Sina,


This looks like an oversight. I can't see any reason why we shouldn't

be reusing stateless property getters/setters.





On Mon, 27 Apr 2020 at 00:20, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:


> Hi everyone,




> I noticed that the getPropertyGetter and getPropertySetter implementations in a lot of models (including PlainXml and Emf) return a new instance every time. Since property accesses are frequent (could be tens of millions of times per program), this results in a lot of unnecessary objects being created and GC’d. I was wondering if this is a bug in the implementation (perhaps a programming mistake), or part of the design? Since judging by the implementations of the getters/setters, there isn’t any state stored – these are effectively pure functions. If so I propose to cache all property getters and setters, which should in theory drastically reduce memory allocations. Intuitively it seems like a costly oversight in the design (in terms of performance) if this is the case, so please let me know if I’m missing something.




> Thanks,


> Sina


> _______________________________________________

> epsilon-dev mailing list

> epsilon-dev@xxxxxxxxxxx

> To unsubscribe from this list, visit





Dimitris Kolovos

Professor of Software Engineering

Department of Computer Science

University of York




epsilon-dev mailing list


To unsubscribe from this list, visit



Back to the top