Ticket #13101 (closed PLIP: fixed)
Update to DateTime 3
Reported by: | hannosch | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.3 |
Component: | Backend (Python) | Version: | 4.3 |
Keywords: | Cc: | hanno@… |
Description (last modified by davisagli) (diff)
Proposer: Hanno Schlichting
Seconder: David Glick
Motivation
Plone is known for being a bit memory hungry. There's a new DateTime version available for some time now, that decreases Plone's memory usage by about 10-20%.
Assumptions
The new DateTime 3 version has been used in a number of both small and large sites for the past year. One of the sites made heavy use of add-ons (about 150 extra packages on the Python path in addition to core Plone). PloneFormGen was the only add-on that needed a tiny change to be compatible with DateTime 3 and that change has long since been released ( https://github.com/smcmahon/Products.PloneFormGen/commit/dc257b05ef1f7a15ba434802b1dffb502c0cde44).
Proposal & Implementation
A small number of code changes have been made a while ago to Zope, CMF and Plone to handle forward compatibility with DateTime 3.
So at this point all that's left is adding a new entry to a versions.cfg.
The new DateTime version changes both the persistent data / pickle format as well as the in-memory layout. The in-memory savings are the more interesting of the two. These apply without the need for any data migration. So the PLIP consciously avoids a big data migration. Over time when content items are changed, the DateTime instances will be saved in the new format.
The new pickle format was a requirement for the in-memory savings, or it would have been avoided. The big difference was using __slots__, which is only available on new-style classes (those having object as a base class). DateTime 2 was still an old-style class. The move from old-style to new-style class itself changed the pickle representation, at which point more optimizations could be done just as well.
Deliverables
DateTime 3 has complete unit tests for the new pickle format and the general DateTime APIs. These should suffice in addition to all existing Plone tests.
The actual DateTime 3 code is long written and released. All the DateTime API's stay the same, so there's no impact on developer API's. The changes are only to internal data structures, so no documentation needs to be updated and there's no impact on translation files.
A new DateTime 2.12.7 release has been made, which includes code to read the new DateTime 3 pickle format. If any major issues arise after an upgrade to DateTime 3, one can easily downgrade to 2.12.7 and all data will be read and converted back to the old format.
Risks
The only risk I could think of was the lack of a downgrade path, which has been addressed with the 2.12.7 release.
Participants
Hanno Schlichting (hannosch)
Progress
All work is done, except updating Plone's versions.cfg.
References
http://pypi.python.org/pypi/DateTime/3.0#changelog http://plone.293351.n2.nabble.com/DateTime-3-improvements-td6344213.html
Change History
comment:2 Changed 4 years ago by davisagli
- Description modified (diff)
I am seconding this one. We are using DateTime 3.0 on our largest site (Plone 4.2) and saw a significant decrease in RAM use when we introduced it. We haven't seen any side effects, and the addition of a downgrade path removes my last concern about it. +1; let's make this happen.