| Re: [eclipse-incubator-e4-dev] Interesting article on modelling with prototype-based leanings |
|
Guys, Comments below. Markus Kohler wrote: Hi Michael,Yes, hash maps are just about the worst case of memory footprint you can imagine, especially given that most implementations use instances of Map.Entry to cause bloat in addition to the large index. The only potential upside of the naive pattern might be huge sparsely populated instances. I.e., you have 1000 feature but only two or three tend to be set on average. Sometimes I make the silly claim that Java doesn't scale because although my hardware has 4G I can't have a heap anywhere close to 2G in size. The cheap memory claim is just silly. It's just a stupid claim. A lot of that talk was about bloat in the byte code and also about static data that can never be garbage collected, but instance size is quite important too. I've been prototyping techniques for significantly reducing the size of EObjectImpl. Perhaps by as much as 50% or more... In my opinion, ever byte saved is a byte earned. :-P I think they all add up. Often people are surprised by the byte code as an issue because it's not an issue that scales, but rather is a constant. I recall a case where folks changed their EMF generation feature delegation pattern from the normal one to the less time efficient Reflection delegation pattern. They also changed the GenPackage's to use Initialize by Loading. They had huge models that generally were used only during initialization. The reduction in byte code resulted in a huge improvement in startup time and a huge reduction in "retained memory", which the the performance loss for data access and the increased memory footprint of the instances had no negative impact. This was an excellent example of the opposite of what you might expect and a great reminder that measurements speak louder than mental exercises and abstract thinking.. I so totally agree. Measure, measure, measure again. Measure everything. And when it comes to performance measurement, remember that the observer often affects the observed and that unfortunately that different JREs and different JIT implementations have a huge impact on performance; often more than the optimizations you might be trying to achieve with the changes you make. Yes, I thought both posts were interesting. Almost like a panacea. :-P A little worse than that, but I'm working on it in my copious spare time. It's always much better than HashHaps, even for dynamic. And the performance is better as well. I think Eric confirmed that a EObject.eGet(feature) is twice as fast as HashMap.get(key), and we even have InternalEObject.eGet(featureID) which is faster yet... In the sense you're using here, the set of properties is fixed; it's just a case of are individual fields allocated per feature, or is an array of slots allocated to hold all the features. That's not quite true either. :-P EMF supports the same type of thing as XML Schema's wildcards. So you can have a property just like <xsd:any>. Other models (<schema>s) can then declare global elements and those global elements (properties of the document root of the corresponding EPackage) can be used as properties on the object with the wildcard property. Yes, I'm not sure I agree with the overall outlook. Often people see difference where I'll see commonalities. For example, I see little significant difference between UML and XML Schema for the purpose of this article. They're both modeling languages, each with a few features the other doesn't have, but modeling languages nevertheless.
|