The issue comes from the fact that for each value we display in the administration of the element, we need to know if user can hide it or if she can delete it. Those two cases depends on semantic, workflow, usage, etc. The previous strategy was to execute two sql requests (containing lot of union statements) for each value. This is bad for performance because it doesn't scale well (it is linear): on my setup with a field containing 40 values, it took 6sec (~150ms * 40) to display the page. The new approach is the following: whenever we request the db to know if we can hide/delete a value I assume we will do the same request for the sibling value of the field. Therefore, instead of asking for one value, we ask for all values of the field, leveraging on MySQL index performances. The result is that it takes only 600ms to display the page with this changeset. Change-Id: Ic2358c0a2e27af06233a3bc9f952b744a290b275

+100 −67

Author

Nicolas Terray (nterray) 2014-06-16 17:24

Committer

Nicolas Terray (nterray) 2014-06-20 14:04

Hash d15ba09f75bb9f307756dd355c7cdcbb333ceba4

Parent 19338c0d6fba9568b4480de2fcf74467ff3822ec

Reference git #tuleap/stable/d15ba09f75bb9f307756dd355c7cdcbb333ceba4