cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <>
Subject Re: Cayenne object storage / memory usage
Date Fri, 09 Jun 2017 18:29:30 GMT
Thanks for commenting! See below.

On Fri, Jun 9, 2017 at 12:48 PM Andrus Adamchik <>

> Ah, an exciting topic!
> > On Jun 9, 2017, at 5:55 PM, John Huss <> 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).

It doesn't have to use reflection. With Java 7 and newer you can use
strings in switch statements with a single jump, which is what I'm doing.
The class template generates the readPropertyDirectly method with the
switch statement in it.  This is both fast and simple.  Also, using fields
makes it much easier to inspect your objects in the debugger, which is

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message