cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Cayenne object storage / memory usage
Date Fri, 07 Jul 2017 05:54:23 GMT

> On Jul 7, 2017, at 3:03 AM, Aristedes Maniatis <ari@maniatis.org> wrote:
> 
> * Does this make debugging memory with a profiler easier since it makes it simpler to
identify field usage?

It makes regular debugging easier, as you no longer need to poke inside the HashMap. Probably
also memory profiling (fewer levels of nesting inside the object make tracing retain paths
simpler).

> * What is the impact on ROP?

None at the moment.

> * Would we want this to be an option for users or is there just no upside to the Map
implementation?

In the past I thought readPropertyDirectly/writePropertyDirectly should be faster with a Map.
But as John and Nikita have demonstrated, this is no longer true with Java 7 switch-based
implementation. Remaining use cases for Map-based objects in my mind are these:

1. Dynamic creation of OR mapping in runtime. I.e. generic objects.
2. A user code that relies on the Map structure to store unmapped properties ("CayenneDataObject.writePropertyDirectly"
will not check the key validity). 

Since both the old and the new objects will follow the same unchanged framework/DataObject
contract, we will preserve full backwards compatibility, allowing users to stay with Map-based
objects if they need to. Really it comes down to a cgen temple selection. So I think in 4.1
we might do the following:

* Make the new cgen template the default (after rigorous testing). 
* CayenneDataObject will stay around and will serve as a base for generic objects and Map-based
objects.
* The old cgen template will be available as an option for those who are concerned with use
case #2.

Andrus
Mime
View raw message