in-radius has very poor performance on generic patch-set (vs patches builtin)

(cross-posted from discussion on the Yahoo! Groups netlogo-users mailing list as per request from Seth)

You also saw http://groups.yahoo.com/group/netlogo-users/message/16734 ,
right?

I did see that, but that edge-case doesn't seem to apply here, as we're working with quite a large patch-set (the geometric mean of the patch-set size in these use cases is probably around 70k).

What I would look at is a small, self-contained test
case or model that isolates and demonstrate an issue
with the minimum necessary code. It's very rare that a
bug or performance issue can't be demonstrated in the
space of 10 lines or so -- like the tests in my
earlier post that you quote. ... If you can come up with one,
please report it at https://github.com/NetLogo/NetLogo/issues/new

I've gotten a mini-testbed up and running, and I've posted a New Issue on the GitHub project. After some more poking around this morning, it seems the root of the problem is in the difference between

patches in-radius N with [some filter]

and

let somepatchset with [some filter]
somepatchset in-radius N

My hypothesis based on reading previous discussion (but without looking at internals) is that the in-radius treats a patch-set the same way it treats any other agentset, rather than recognizing that it's dealing with patches. The first version is an acceptable workaround in cases where [some filter] is inexpensive, or where count somepatchset is of roughly the same order of magnitude as count patches, or where somepatchset is not commonly reused, but it's not at all difficult to construct scenarios where these conditions breakbown, and it's not at all intuitive that these apparently semantically-equivalent queries should have such drastically different performance characteristics (particularly since, from an end-user API perspective, patches appears indistinguishable from an ordinary patch-set).

Here's a link to my self-contained example:
http://sfgp.cemetech.net/srcs/netlogo-in-radius-problem-sample.zip
In the Interface pane, press the Setup button, then press the Profiling button.

cf. "[netlogo-users] in-radius efficiency question" thread on netlogo-users mailing list on Yahoo! Groups.

Download the linked self-contained example, press Setup, then Profiling, and compare patches in-radius N with [some filter] with the equivalent filtered patch-set query. Start by reproducing the reported performance difference and tracing the in-radius handling of patch-sets. Done means the two semantically equivalent forms no longer show the reported drastic performance gap.