[buddypress-trac] [BuddyPress Trac] #8688: BP_Groups_Group::get_total_member_count() is highly inefficient, and runs out of memory

[buddypress-trac]

#8688: BP_Groups_Group::get_total_member_count() is highly inefficient, and runs
out of memory
--------------------------+---------------------
 Reporter:  dd32          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  10.3.0
Component:  Groups        |     Version:  10.0.0
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+---------------------

Comment (by dd32):

 Replying to [comment:13 dd32]:
 > but from reading the code and how it's implemented, this looks great to
 me!

 Some thoughts though:
  - It's a little strange that `bp_groups_defer_group_members_count()`
 doesn't call `bp_groups_update_group_members_count()` directly, when
 that's the function it's hooking back on. I can see from the code that
 it's just a wrapper, but it still feels odd.
  - `( true === $groups_member instanceof BP_Groups_Member )` seems a
 little redundant, the `true ===` part I mean; instanceof seems to be
 enough of a comparator to use there?
  - `bp_groups_defer_group_members_count( $group_id, true );` to defer
 counting, where it affects all group operation and not just the group_id
 passed is a little odd. I'd expect either just:
    - defer: `bp_groups_defer_group_members_count( true );
    - post-defer: `bp_groups_defer_group_members_count( false, $group_id
 );`
      - or `bp_groups_defer_group_members_count( false )` and it to have
 known which `$group_id`s need reprocessing (which should be a singular
 group, but technically could've been more, maybe?)

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8688#comment:14>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac