Ticket #8792 (confirmed Bug)

Opened 7 years ago

Last modified 3 years ago

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

keywords.diff Download (3.1 KB) - added by potzenheimer 5 years ago.
Replacing calls to unicodeTestIn.py Restricted Python scribt with getSelected function from @@at_selection_widget browser view

Change History

comment:1 Changed 7 years ago by hannosch

  • Milestone set to 3.x

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.

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

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.

comment:5 Changed 4 years ago by toutpt

  • Status changed from new to confirmed
  • Version set to 4.1

comment:6 Changed 3 years ago by eleddy

  • Keywords tuneup added
Note: See TracTickets for help on using tickets.