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" <[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]
