Re: SVN: zope.component/trunk/ Optimized un/registerUtility via storing an optimized data structure for
Hanno Schlichting wrote:
Log message for revision 81348: Optimized un/registerUtility via storing an optimized data structure for efficient retrieval of already registered utilities. This avoids looping over all utilities when registering a new one.
You are changing what looks like persistent datastructures. Are you sure this doesn't introduce backwards compatibility issues? I also question naming the next release 3.4.1. This is not a bugfix. I think it should come in as 3.5. Regards, Martijn
Martijn Faassen wrote:
Hanno Schlichting wrote:
Log message for revision 81348: Optimized un/registerUtility via storing an optimized data structure for efficient retrieval of already registered utilities. This avoids looping over all utilities when registering a new one.
You are changing what looks like persistent datastructures. Are you sure this doesn't introduce backwards compatibility issues?
Sorry, you are right. I changed it to only optimize non-persistent registries and fall back on the algorithm which doesn't need an optimized new data structure as before.
I also question naming the next release 3.4.1. This is not a bugfix. I think it should come in as 3.5.
I'm not sure what criteria determine if something is a feature change and what is not, so I changed the next version on trunk to 3.5. Hanno
Hanno Schlichting wrote:
Martijn Faassen wrote:
Hanno Schlichting wrote:
Log message for revision 81348: Optimized un/registerUtility via storing an optimized data structure for efficient retrieval of already registered utilities. This avoids looping over all utilities when registering a new one. You are changing what looks like persistent datastructures. Are you sure this doesn't introduce backwards compatibility issues?
Sorry, you are right. I changed it to only optimize non-persistent registries and fall back on the algorithm which doesn't need an optimized new data structure as before.
Does it still install the optimized datastructure if you create a new persistent registry?
I also question naming the next release 3.4.1. This is not a bugfix. I think it should come in as 3.5.
I'm not sure what criteria determine if something is a feature change and what is not, so I changed the next version on trunk to 3.5.
I think the criteria should be very simple: if it's a bugfix, you can release a bugfix release. If it's anything else, make it a feature release. Optimization is a feature, not a bugfix. The combination here would've been particularly bad: people innocently try version 3.4.1 and suddenly find their ZODB is broken. :) Note that I'm actually quite excited to see optimization work - this is why I paid particular attention to your checkin at all. Thanks for looking into this stuff! Regards, Martijn
Martijn Faassen wrote:
Hanno Schlichting wrote:
Martijn Faassen wrote:
Hanno Schlichting wrote:
Log message for revision 81348: Optimized un/registerUtility via storing an optimized data structure for efficient retrieval of already registered utilities. This avoids looping over all utilities when registering a new one. You are changing what looks like persistent datastructures. Are you sure this doesn't introduce backwards compatibility issues?
Sorry, you are right. I changed it to only optimize non-persistent registries and fall back on the algorithm which doesn't need an optimized new data structure as before.
Does it still install the optimized datastructure if you create a new persistent registry?
No, it doesn't do that at all anymore. The only thing that is speed up is registering and unregistering utilities which shouldn't happen for persistent registries all that often. In a standard Plone site you have about 1800 global utilities and registering those at Zope startup time has been quite slow, as the former algorithm looped through all already registered utilities when adding a new one.
I also question naming the next release 3.4.1. This is not a bugfix. I think it should come in as 3.5.
I'm not sure what criteria determine if something is a feature change and what is not, so I changed the next version on trunk to 3.5.
I think the criteria should be very simple: if it's a bugfix, you can release a bugfix release. If it's anything else, make it a feature release. Optimization is a feature, not a bugfix.
The combination here would've been particularly bad: people innocently try version 3.4.1 and suddenly find their ZODB is broken. :)
Note that I'm actually quite excited to see optimization work - this is why I paid particular attention to your checkin at all. Thanks for looking into this stuff!
We are sitting here in Copenhagen on the Plone performance sprint and found some more interesting pieces... stay tuned ;) Hanno
participants (2)
-
Hanno Schlichting -
Martijn Faassen