Re: POJOs

Thanks for the explanation and example.  You are right, in terms of  
CPU cycles POJOs would be slower in my system.  So really it comes  
down to memory.  Eventually everyone will have 64 bit OS's and 64 bit  
JVM's, but for now I'm having trouble with the 2GB (really 1.6GB or  
1.2GB under windows) maximum heap size.

That, and an unwillingness to mess with stable code -- I would have to  
change all my scientific simulation code to use the ParcelInterface  
instead of the Parcel, so that it could use a SimpleORMParcel or a  
POJO Parcel.   Probably not a big deal, but I'm proud of code  
stability whenever it occurs.

I do have another section of the system where the same fields ARE  
accessed many thousands of times -- and that code is very very  
stable.  But that is not the part I'm currently working on.

Anyways, that was useful information, thank you.

--
John


On 24-Oct-08, at 1:55 AM, Anthony & Melissa Berglas wrote:

> Hello John,
>
> It is rarely a good idea to use POJOs. If you implement get and set
> methods then the simpleORM records will look just like POJOs  
> externally.
>
> Internally SimpleORM records are an array of objects. Accessing the
> array is very fast, but there is some overhead in boxing up integers
> and floats into Objects. If you are accessing a field on the SAME
> object thousands of times then a POJO might be justified. But that
> is very rare. If you are accessing a thousand records then the
> creation of POJOs will probably slow you down.
>
> In all these performance issues I strongly suggest that you first
> implement a simple solution, then carefully profile it, and only then
> perform optimizations. Inevitably the bottlnecks will not be where
> you expect them.
>
> If you do want to create POJOs then write a generic method
> Object createPOJO(class pojoClass, SRecordInstance instance)
>
> I have attached code that does a similar thing for a different
> package (SimpleWebApp) but it demonstrates the general
> technique. If you write this cleanly with a test case then I will
> add it to the SimpleORM package.
>
> Regards,
>
> Anthony
>
> At 02:35 AM 23/10/2008, you wrote:
>
> >Hello there. I used SimpleORM for some projects a few years ago,  
> but I
> >really wanted to use POJOs, primarily because of the sheer volume of
> >objects (and resulting memory constraints) but also because I was
> >retrofitting an old project that had used plain JDBC calls and custom
> >object-creation-from-query routines.
> >
> >So I tried Hibernate for a while. Turns out, much to my surprise,  
> that
> >Hibernate uses "pseudo-POJO's" with a byte-code enhancer. Sucky. :(
> >
> >Now that I've given up on Hibernate, for that reason and the other
> >obvious reasons, and since SimpleORM has had some further  
> development, I
> >think I'll go back to SimpleORM. I'll probably use a combination of
> >direct JDBC and SimpleORM in the next development cycle, just to make
> >sure I'm building on the code that actually works already.
> >
> >So now I'm left with wondering how to best create POJOs from  
> Hibernate
> >objects. For instance, I have a ParcelInterface, representing the
> >behaviour of a legal parcel of land in my simulation. I have two
> >classes that implement ParcelInterface: SimpleORMParcel, which uses
> >SimpleORM, and Parcel, which uses shorts, floats and chars as much as
> >possible (instead of ints, doubles and strings) so that I can fit as
> >many Parcels into memory as possible.
> >
> >What I'm wondering about is the best way of creating Parcels using
> >SimpleORM. Presumably I'd create SimpleORMParcels simply using
> >SimpleORM, and then create Parcels from the SimpleORMParcels.
> >
> >Perhaps I would have a query that makes 10,000 SimpleORMParcels at a
> >time, and then have a method SimpleORMParcel.createPlainOldParcel:
> >public Parcel createPlainOldParcel()
> >which I would call 10,000 times to create a POJO memory-lean Parcel  
> from
> >the SimpleORMParcel.
> >
> >Or perhaps I would have a static method
> >static public Parcel createPlainOldParcel(SimpleORMParcel
> >theSimpleORMParcel)
> >
> >Or perhaps I'd do something completely different?
> >
> >I realize I should probably read about the Data Access Objects  
> pattern
> >(DAO), but I suspect there is "best way" to do it using SimpleORM  
> that
> >someone else has already figured out, that they could share with me.
> >
> >Again, I think I need to use POJOs for three reasons:
> >1) to keep memory use down,
> >2) to keep speed up (it is a scientific numerical simulation, I
> >sometimes use direct field access instead of get() and set() just to
> >make things a tiny bit faster)
> >3) I have legacy code that uses these POJOs
> >
> >Perhaps I'm wrong about needing to use POJOs, so advice to the  
> contrary
> >is welcome.
> >
> >Thanks,
> >
> >--
> >John Abraham
> ><mailto:jabraham%40ucalgary.ca>[email protected]
> >
>
> Spreadsheet Detective,
> Southern Cross Software Queensland Pty Limited
> 54 Gerler Street
> Bardon, Queensland 4065, Australia.
>
> Email: [email protected]
> www.SpreadsheetDetective.com
> Ph: +61 427 830248 (Australian Eastern Standard Time)
>
> "If the model seems correct only because the numbers look right,
> then why build the model in the first place?"
>
>  <2734d536.jpg><WBeanUtils.java>