Ah! Really nice catch!

On the actual patch here, do we lose much performance if we simplify a little bit? Specifically, I'd like to avoid having two loops which implement the same filters. A proposed simplification is to retain a single loop, but do this instead:

+ $set = $this->resultSet;
+ if ($src_phids) {
+   $set = array_select_keys($set, $src_phids);
+ }
- foreach ($this->resultSet as $src => $edges_by_type) {
+ foreach ($set as $src => $edges_by_type) {

Then do something similar for $types. I think that would let us get rid of the top-level if/else and sort-of-duplicated code, but should give us the bulk of the performance benefit?

One inline about array_merge(). Here's a simple example for the array_merge() issue:

<?php

$N = 10000;

$t_start = microtime(true);

$result = array();
for ($n = 0; $n < $N; $n++) {
  $result[] = $n;
}

printf(
  "Append %d elements with operator[] in %dms.\n",
  count($result),
  1000 * (microtime(true) - $t_start));


$t_start = microtime(true);

$result = array();
for ($n = 0; $n < $N; $n++) {
  $result = array_merge($result, array($n));
}

printf(
  "Append %d elements with array_merge() in %dms.\n",
  count($result),
  1000 * (microtime(true) - $t_start));

On my system, the array_merge() cost jumps from 38ms to 6889ms when N jumps from 1000 to 10000 (181x slower with an input 10x larger). The cost of using [] to append with N=10000 is 1ms.

The numbers here probably aren't big enough to start hitting the bad parts of this behavior, but you could imagine that a task could reasonably have 10K edges (e.g., 10,000 subscribers).

My general approach to avoiding this is to never array_merge() in a loop. You can array_mergev() (convenience method provided by libphutil) after the loop, or iterate + operator[] in a loop, or use array + array (all of which have costs on the order of O(N) in the total number of elements, but none of which is a drop-in replacement for array_merge, per se).