Weighted proposal voting causes slowness on proposals index page

[Quentinchampenois]

Describe the bug
A clear and concise description of what the bug is.

Hello, I share with you slowness we had on a production instance. The feature Weighted proposal voting appears to really slow down the loading of the proposals index page.

I haven't investigate a lot but I think there is a query n+1 in the proposal_m_cell_override or caching issue maybe.

About the application :

• Decidim v0.27.5
• DecidimAwesome: Branch release/0.27-stable and commit c72e7f0fa0fe98807ace8414ecc08cbf44ce72d5
• 600 proposals and 600 ProposalExtraField in database

To Reproduce
Steps to reproduce the behavior:

1. Enable caching mode
2. Enable Private fields
3. Populate database with proposals and private fields
4. See loading slower

Expected behavior
A clear and concise description of what you expected to happen.

I expect the loading page to remain stable

Quick fix

Deactivate the feature weighted_proposal_voting if not used 👍

Example: config/initializers/decidim_awesome.rb

Decidim::DecidimAwesome.configure do |config|
  config.weighted_proposal_voting = :disabled
end

Example of rendering time when activating and disabling the feature :

--------- With the weighted_proposal_voting enabled
[5400a7ce-4888-4cb3-97a0-0679b1a57269] [127.0.0.1] Completed 200 OK in 5965ms (Views: 5310.3ms | ActiveRecord: 578.5ms | Allocations: 5574239)
[0188884e-70bf-4388-9042-6464a93d3011] [127.0.0.1] Completed 200 OK in 4866ms (Views: 3645.9ms | ActiveRecord: 979.1ms | Allocations: 2583164)
[a83a965d-fe61-4246-88b2-9d116f3ac3f0] [127.0.0.1] Completed 200 OK in 2407ms (Views: 2221.7ms | ActiveRecord: 127.0ms | Allocations: 1004768)
--------- With the weighted_proposal_voting disabled
[d2f56eed-5ccb-4d4c-8c2b-5e77f7296b3a] [127.0.0.1] Completed 200 OK in 2791ms (Views: 2460.7ms | ActiveRecord: 256.8ms | Allocations: 3737530)
[3db5737a-2cc8-489f-bac0-c014f13dfaad] [127.0.0.1] Completed 200 OK in 734ms (Views: 580.0ms | ActiveRecord: 96.6ms | Allocations: 698351)
[b70c1b26-6ce0-4dbd-beaa-b83bf98f9fb1] [127.0.0.1] Completed 200 OK in 629ms (Views: 455.4ms | ActiveRecord: 85.7ms | Allocations: 697724)

[microstudi]

I've been investigating a bit this and I couldn't replicate this degradation of performance. I've tested thge 0.28 version though.

On the other hand, I don't see how this method generates a n+1 query, in any case just one more query per proposal (which effect is mostly negligible considering the amount of other queries around).

But please, add more information if you can.

Maybe this is relevant decidim/decidim#13701

[microstudi]

@Quentinchampenois
I've made a PR to improve the performance in Awesome that should affect your case.

The backport for the version 0.27 is here:
This is the PR #359

You thing you can try it in your environment? see if there's any gain?