Ticket #8792 (confirmed Bug)
keyword widget: performance issue in edit mode
Reported by: | toutpt | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 4.x |
Component: | Archetypes | Version: | 4.1 |
Keywords: | tuneup | Cc: |
Description
The time to compute edit mode of the keyword widget increase by n² (n=how many keywords you have selected).
How to reproduce: On a production server with Plone2.5 i have selected all the keywords and submit. Next try to edit the properties.
Note: Some one must confirm that it is also the case with Plone3.X
Results of the profiling (done with Callprofiler): n = 363 n2 = 131 769 PythonScript: unicodeEncode 0.0009sec per call with 131769 calls=>118sec
Hits Recent Hits Misses Memory Entries /plone/unicodeEncode 129969 129969 372 60144 372 /plone/unicodeTestIn 0 0 363 2058368 363
To fix this i have modify the keyword.pt, unicodeTestIn.py and unicodeEncode.py to be able to associate those two PythonScripts with RamCache. As results i have a rendering time of 22sec of the properties form. it's not fix the problem but it is a lot better than 130sec.
Here are the diffs: keyword.pt, change call to PythonScript unicodeTestIn from 'here' to 'portal' because RamCache make key with context of the call, and the context is not usefull for those two PythonScript.
keyword.pt
57c57 < selected python:test(here.unicodeTestIn(keyword, value), 'selected', None)"> --- > selected python:test(portal.unicodeTestIn(keyword, value), 'selected', None)">
unicodeTestIn
9c9,10 < --- > from Products.CMFCore.utils import getToolByName > portal = getToolByName(context, 'portal_url').getPortalObject() 13,14c14,15 < value = context.unicodeEncode(value) < vocab = [context.unicodeEncode(v) for v in vocab] --- > value = portal.unicodeEncode(value) > vocab = [portal.unicodeEncode(v) for v in vocab]
unicodeEncore.py
8a9,10 > from Products.CMFCore.utils import getToolByName > portal = getToolByName(context, 'portal_url').getPortalObject() 15c17 < encoded = [context.unicodeEncode(v) for v in value] --- > encoded = [portal.unicodeEncode(v) for v in value]
Attachments
Change History
comment:2 Changed 5 years ago by potzenheimer
- Priority changed from minor to critical
- Milestone changed from 3.3.x to 4.1
Since we just got bitten by this in a customer project with ~2000 unique keywords where the edit form for items with 10+ keywords selected takes up to 2 min to load, I stumbled upon this ticket.
The attached diff patches keyword.pt in Products.Archetypes to no longer use the Restricted Python Script unicodeTestIn.py but instead rely on the @@at_selection_widget view.
Since PLIP: Tags MultiSelectionWidget w/scrollbar & checkboxes is scheduled for inclusion in PLone 4.1 fixing this performance issue is imho long overdue.
Changed 5 years ago by potzenheimer
-
attachment
keywords.diff
added
Replacing calls to unicodeTestIn.py Restricted Python scribt with getSelected function from @@at_selection_widget browser view
comment:3 follow-up: ↓ 4 Changed 5 years ago by hannosch
- Owner nouri deleted
- Priority changed from critical to major
The issue isn't critical for Plone at large - that would mean it would almost block any new maintenance release. Since this only happens in rare cases where you have lots of keywords it's not affecting too many sites. Still a major issue though.
comment:4 in reply to: ↑ 3 Changed 5 years ago by potzenheimer
Replying to hannosch:
The issue isn't critical for Plone at large - that would mean it would almost block any new maintenance release. Since this only happens in rare cases where you have lots of keywords it's not affecting too many sites. Still a major issue though.
Duh - had meant to make it a major issue in the first place. My mistake.
Sorry for maybe making too much noise, but I actually added a comment on the PLIP since it is imho a shame that the keyword widget gets reworked but still includes slow Restricted Python code that should have been replaced years ago.
Please confirm this on Plone 3.x. We rewrote the widget for better performance IIRC and removed the various scripts in favor of a browser view.