I made a mistake about n,m. I had them reversed. werner --> Wrt your problem. Steve --> The cost for loading an object from the database is O(n^m) where m is the number of dependent classes and n is roughly the number of instances per class (rows in the child table). I will gladly submit the patch, I just wanted to make sure that my approach was sound.
----- Original Message ----- From: "Stephen Ince" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 29, 2004 10:18 AM Subject: Re: [castor-dev] JDO object creation performance flaw > I have attached the relevant portion of my mapping file. > > Ooops about the html emails. > > werner --> I hope this does not come across as too harsh ..... > Steve --> Not offended. I think constructive discourse is a good thing. > I have been using Castor for 1 1/2 years. In general I really like the > Castor project, especially the XML side of it. I think you guys do an > outstanding job. > > werner --> I'd be the first one to contribute, as I plan to add support for > lazy-loading simple 1:1 relations. > Steve --> I think it is an issue for 1:m relations and not for 1:1 > relations. > > werner --> Wrt your problem. > Steve --> The cost for loading an object from the database is O(n^m) where n > is the number of dependent classes and m is roughly the number of instances > per class (rows in the child table). I will gladly submit the patch, I just > wanted to make sure that my approach was sound. > > werner --> I still have to find out whether you are using vanilla 1:M > relations between web_resource and all the other classes or whether you are > using DEPEND relations (as well). > Steve --> They are all dependent 1:M relations. > > > ----- Original Message ----- > From: "Werner Guttmann" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 29, 2004 4:42 AM > Subject: Re: [castor-dev] JDO object creation performance flaw > > > > > > Stephen, > > > > a couple of random observations .... mostly inline. But before doing so, > can I please ask you respect the mailing list guidelines for this mailing > list and > > refrain from sending text/html messages. > > > > Regards > > Werner > > > > --Original Message Text--- > > From: Stephen Ince > > Date: Mon, 28 Jun 2004 21:26:24 -0400 > > > > I just wanted to start the discourse. I think in general open source > projects are not that strong in the design review process. > > > > werner --> What makes you think that his statement is correct ? I have > been working for companies sich as Clearstream and Morgan Stanley, and in > > general I think the reverse is correct. But it would be correct to say > that a open source project is only as good as it users and the code that is > being > > contributed by the community. As it stands now, we are three committers > working on several critical and no-critical issues, incl. refactoring and > redesign > > of various system aspects. If you had been familiar with several of the > discussions going on at http://bugzilla.exolab.org, you might rethink what > you've > > just said. > > > > Wrt your problem, I still have to find out whether you are using vanilla > 1:M relations between web_resource and all the other classes or whether you > are > > using DEPEND relations (as well). > > > > This would have probably been caught in design review. > > > > werner --> Yes, it should have been. But where have you been when this > feature has been designed ? See, it's all about perception and how far you > are > > willig to go towards contributing code/design/functionality/etc. I for > myself would enthusiastically welcome any contribution from you, indeed. > > > > I think it would be beneficial if the group could collectively agree on a > solution before any implementation is done. > > > > werner --> If the above statement were to be replaced with 'I think it > would be beneficial if the group could collectively work towards an > implementation', > > I'd be the first one to contribute, as I plan to add support for > lazy-loading simple 1:1 relations. > > > > werner --> I hope this does not come across as too harsh, as I genuinly do > not have any intentions to upset you. > > > > ----- Original Message ----- > > From: Gregory Block > > To: [EMAIL PROTECTED] > > Sent: Monday, June 28, 2004 7:57 PM > > Subject: Re: [castor-dev] JDO object creation performance flaw > > > > > > On 28 Jun 2004, at 23:52, Stephen Ince wrote: > > Castor should probably use separate queries to load the dependent objects. > > > > > > On our own project, I must admit, we hit this. Big time. Performance > suffered dreadfully; our only recourse was to hand-code getters to lazy load > on use, > > rather than try to load them all in individual queries. > > > > We've since gone a very different route - using memcached to distribute > cached objects into a distributed pool of out-of-JVM caches that we run in > the > > live service, and moved all of our queries out of OQL-based object loads > into cache lookups and pinpoint loading of individual IDs through db.load, > > preserving object instances in cache, including instances common to more > than one object. > > > > Anything that can be done to improve the performance of that call is > appreciated. > > > > > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > > > > > > ----------------------------------------------------------- > > If you wish to unsubscribe from this mailing, send mail to > > [EMAIL PROTECTED] with a subject of: > > unsubscribe castor-dev > > > ---------------------------------------------------------------------------- ---- > ----------------------------------------------------------- > If you wish to unsubscribe from this mailing, send mail to > [EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
