Actually, cacheing voting power is a bad idea because the formula can be changed. Perhaps cache total points of voters who voted for each answer + the poll itself instead.

Discussed this with Patrick.

Regarding Patrick's reply:
Caching points for each answer doesn't work as there is no linear relationship to calculate voting power from the combined points of each member.

The real solution would be:
1) Add a nullable field cache_voting_power on each answer row.
2) Add a nullable field cache_voting_power on each vote row.
3) If the cache_voting_power value is set when loading polls in topicview, use it, don't do a full calculation
4) If the cache_voting_power value is null on an answer row when loading polls the topicview, do the full calculation as we do now, updating cache_voting_power on the voter rows at the same time
5) If the cache_voting_power value is set when showing voters, use it, don't do a full calculation
6) If the cache_voting_power value is null on an answer row when showing voters, do the full calculation as we do now
7) When a vote is cast, the cache_voting_power on the answer row should be set and the cache_voting_power value on the answer row should be raised as appropriate
8) When a vote is revoked, the cache_voting_power value should be lowered based on the value of the vote row being revoked.
9) If the configuration changes on any of the relevant config options, flush out these field values from the database (nullify them). This should be done via a hook that listens to particular config options changing. If we don't yet have such a hook type, we should add it.

Additionally:
1) Viewing voters does not need to do an in-memory sort if ordering by voting power. Voting power is strictly proportional to number of points, so it can just do an in-DB sort on the points column.

Update docs to reflect the efficiency no longer exists.