Hello,
I made a small modification to zodbupdate that makes it quite faster. Please give it a quick review.
svn://svn.zope.org/repos/main/zodbupdate/branches/adamg-faster
On Wed, 29 Sep 2010 09:53:37 +0200 Adam GROSZER agroszer@gmail.com wrote:
Hello,
Hello,
I made a small modification to zodbupdate that makes it quite faster. Please give it a quick review.
svn://svn.zope.org/repos/main/zodbupdate/branches/adamg-faster
I don't think your fix cover all cases.
Correct me if I am wrong, what you do is not unpickle class data pickle unless the class_meta information pickle of that record changed, and need update ?
However, that imply that this doesn't update anymore any class reference that is not itself persistent (so is only in the class data pickle) and not used by a persistent renamed-as-well class (otherwise the change in the class_meta pickle would trigger an update of this record).
If we want to make it faster, all I can see is pack the database before, as it would contain less records to go through after. I am not sure, that adding parallelism would help a lot, unless you have the good hardware for, but we could make it to see (it is not that difficult).
On which database size you want to make it faster ? I had 20Go databases and it toke less than one hour, if I remember correctly. It's long, but I don't see how to make it faster, in the code itself.
Regards,
Sylvain,
Hello Sylvain,
Wednesday, September 29, 2010, 10:36:15 AM, you wrote:
I made a small modification to zodbupdate that makes it quite faster. Please give it a quick review.
svn://svn.zope.org/repos/main/zodbupdate/branches/adamg-faster
SV> I don't think your fix cover all cases.
SV> Correct me if I am wrong, what you do is not unpickle class data pickle SV> unless the class_meta information pickle of that record changed, and SV> need update ?
SV> However, that imply that this doesn't update anymore any class SV> reference that is not itself persistent (so is only in the SV> class data pickle) and not used by a persistent renamed-as-well class SV> (otherwise the change in the class_meta pickle would trigger SV> an update of this record).
SV> If we want to make it faster, all I can see is pack the database SV> before, as it would contain less records to go through after. I am SV> not sure, that adding parallelism would help a lot, unless you have SV> the good hardware for, but we could make it to see (it is not that SV> difficult).
SV> On which database size you want to make it faster ? I had 20Go SV> databases and it toke less than one hour, if I remember correctly. SV> It's long, but I don't see how to make it faster, in the code itself.
On the second look I guess you're right. It just needs to unpickle everything. I removed the branch, reliability goes over speed.
Would you make a release from the trunk? I added there some more logging.