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]
