Or we just cherry-picked the one easy thing Andreas recommended ;-) ----- Original Message ----- From: "Oliver Zeigermann" <[EMAIL PROTECTED]> To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> Sent: Monday, August 02, 2004 9:41 AM Subject: Re: How to make Slide faster
> Maybe it is not more complicated, but I am just less smart than you ;) > > Oliver > > Jim Myers wrote: > > > Will do. Just thought that since the response to Andreas was > > > > > >>>>thanks for your input. I guess you are right, but those changes much > >>>>more sound like a redesign of Slide. > > > > > > that we'd check on the list to see if we were missing something that would > > make this fix more complicated than it looked. > > > > Jim > > > > > > ----- Original Message ----- > > From: "Oliver Zeigermann" <[EMAIL PROTECTED]> > > To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> > > Sent: Monday, August 02, 2004 3:33 AM > > Subject: Re: How to make Slide faster > > > > > > > >>I can only repeat myself. This would be cool! > >> > >>Oliver > >> > >>Jim Myers wrote: > >> > >> > >>>A bit more info - I think this is analogous to what Andreas wanted, we > > > > just > > > >>>tried it on properties first. But the idea of keeping a dirty > > > > flag/change > > > >>>list around should be generic. Since tracking changes is all within one > >>>class, e.g. NodeRevisionDescriptor, you just need a way to get the > > > > changes. > > > >>>Should be backwards compatible since stores that ignore the list can > > > > just do > > > >>>as they do now and delete/store everything. To make use of the list, > > > > only > > > >>>the class that calls the database needs a change. > >>> > >>>Tara's tests weren't showing huge improvements when setting a property > > > > or > > > >>>two with 10+ defined, but it was 10-20% and, I would expect, would help > >>>remove some of the scaling issues with large numbers of properties or, > >>>analogously, large numbers of children, etc. > >>> > >>> Jim > >>> > >>> > >>>----- Original Message ----- > >>>From: "Talbott, Tara D" <[EMAIL PROTECTED]> > >>>To: <[EMAIL PROTECTED]> > >>>Sent: Friday, July 30, 2004 6:29 PM > >>>Subject: RE: How to make Slide faster > >>> > >>> > >>>Another idea for speedup is to reduce unnecessary changes to the > >>>database. > >>>For example when storing a revision in the StandardRDBMSStore it removes > >>>all properties, then reinserts all of them, even it its only changing > >>>one property. If we track the properties that have been modified in > >>>NodeRevisionDescriptor, then delete/create only those properties then > >>>there should be an improvement in speed when modifying any existing > >>>revisions. This same principle should also be possible when storing > >>>Objects. I tried implementing this on Node RevisionDescriptors and did > >>>see an improvement in speed. > >>> > >>>This shouldn't be too major of change, at lease it wouldn't require a > >>>complete redesign. And it should be backwards compatible. Can anyone > >>>think of any reasons why this could cause problems with other stores? > >>>What do you think? Let me know if you would like me to email you the > >>>changes. > >>> > >>>Tara > >>> > >>> > >>> > >>> > >>>----- Original Message ----- > >>>From: "Oliver Zeigermann" <[EMAIL PROTECTED]> > >>>To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> > >>>Sent: Monday, July 26, 2004 4:22 PM > >>>Subject: Re: How to make Slide faster > >>> > >>> > >>> > >>> > >>>>Hi Andreas, > >>>> > >>>>thanks for your input. I guess you are right, but those changes much > >>>>more sound like a redesign of Slide. I am afraid this is something > >>>>hard to avoid sooner or later. And I really think with the experience > >>> > >>>>from how Slide is used and where the bottlenecks are can only be fully > >>> > >>> > >>> > >>>>implemented in a 3.0 release. I have no idea when and if we all > >>>>finally find time to make it real. > >>>> > >>>>For now, do you have anything simple that might get a little more > >>>>performance out of Slide? I haven't ;) > >>>> > >>>>Oliver > >>>> > >>>>Andreas Probst wrote: > >>>> > >>>> > >>>> > >>>>>Hi Oliver, > >>>>> > >>>>>there are two major issues which should be fixed to make Slide much > >>>>>faster, especially with high volumes: > >>>>> > >>>>>- load and instance the children of a collection only when they are > >>>>>needed, not in stock. > >>>>> > >>>>>- when children are added or removed, don't remove n children from > >>>>>the database just to add n+1 or n-1 afterwards again > >>>>> > >>>>>To achieve this the DescriptorsStore interface could be enhanced. > >>>>> > >>>>>Then I think the fact, that an instanced child of a collection is > >>>>>not necessarily in the cache, could lead to memory problems. Due to > >>>>>the chaining of children and parent objects the size of the > >>>>>ObjectNodes can vary very much. I think it would be better for > >>>>>caching and memory usage to retrieve children objects not from a > >>>>>SubjectNode but from the cache or store. > >>>>> > >>>>>Just in case you would like to change a bit more ;-) > >>>>> > >>>>>Regards, > >>>>> > >>>>>Andreas > >>>>> > >>>>>On 26 Jul 2004 at 15:33, Oliver Zeigermann wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I am currently thinking about how Slide could be made faster with > >>>>>>little effort. As the main source of Slide being slow I identified > >>>>>>method > >>>>>> > >>>>>>public ObjectNode retrieve(SlideToken token, String strUri, > >>>>>> boolean translateLastUriElement) > >>>>>> > >>>>>>in StructureImpl and lock and securiy checks. > >>>>>> > >>>>>> > >>>>>>As I don't want to change much, maybe some sort of *direct* caching > >>>>>>could do that maps the string Uri to the Object Node resp. to > >>>>>>locking and security data. It would, however, be complicated to > >>>>>>determine which calls to Slide invalidate the entries. > >>>>>> > >>>>>>Any ideas? Comments? > >>>>>> > >>>>>>Oliver > >>>>>> > >>>>>>-------------------------------------------------------------------- > >>>>>>- > >>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>-------------------------------------------------------------------- > >>>>>- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>> > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
