You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <ol...@zeigermann.de> on 2004/08/02 09:32:09 UTC

Re: How to make Slide faster

I would be great if you contributed your code to Slide. If you decide to 
do so it might be best to create an issue in the bugzilla and attach 
your code there. If this does not work for you, try sending it to the list.

Oliver

Talbott, Tara D wrote:

> 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" <ol...@zeigermann.de>
> To: "Slide Developers Mailing List" <sl...@jakarta.apache.org>
> 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: slide-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>
>>>
>>>--------------------------------------------------------------------
>>>-
>>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org