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, 09 Jun 2017 17:48:20 GMT
Ah, an exciting topic!

> On Jun 9, 2017, at 5:55 PM, John Huss <johnthuss@gmail.com> wrote:
> For my test of loading 10,000 objects from every table in my database I got
> it to use about about *half the memory* of the default class (from 921 MB
> down to 431 MB).

Yeah, that's certainly expected.

> So one question is how we should be addressing the need that people may
> have to create their own data classes. Right now I believe the recommended
> path is to subclass PersistentObject,

Formally - yes. But we don't have a "recommended" way from the practical standpoint. Simply
because this is too complicated for the majority of users. The most prominent example of an
alt Persistent implementation is ROP, but it required a bunch of other things to work beyond
the object itself and ClassDescriptor. So I commend you for trying! :)

> Another approach might be to ask why anyone should need to customize the
> way data is stored in the objects if we can just use the best solution
> possible in the first place?

+1. While making it pluggable is nice (even for our own experimentation), the goal is to settle
on the most efficient design and make it the default.

>  I can't imagine a more efficient representation that fields.  

True, but fields also require reflection to be accessed "from below" (by Cayenne). Other ideas
include:

* use Object[] for data storage (with array positions alphabetically mapped to attribute names).
* use fields, but also use class generation (that you also mentioned) to create some kind
of "companion" objects (adapters) for each entity, that can operate on the fields of a given
Persistent object, but present a generic API to the rest of the framework.

> However, fields present difficulties for the
> use case where you aren't generating unique classes for your model but just
> rely on the generic class.  

I'd keep Map-based CayenneDataObject for the 5% of apps that use generic classes. (Unless
we can make Object[] based structures to work. Those are also generic).

Andrus
Mime
View raw message