Could you do a performance comparison with a single fairly high poly mesh, with around half the vertices selected?

For changes to internal workings like this we should take care it doesn't introduce performance regressions.

If this diff isn't suitable, an alternate version of set_prop_dist(...) (which is more of a straight 'N2' multi-object upgrade) can be found here D5163.

Note that at the date of this diff, any objects that are being edited that don't have a vertex selected won't have a TransDataContainer - in other words if an object doesn't have at least one selected vertex it will not be affected by proportional editing.

Timings are from a 2013 computer. Timings from the original code ('N2') and code from D5163 ('new N2') are fairly consistent - which vertices are selected doesn't have much affect on timings. Timings for this diff are affected by which vertices are selected ('kdTree' and 'kdTree Bad Case').

50% vertex selection timings (3D viewport):

A handful of KdTree times for different vertex selections:
128K: 1.37s, 1.52s, 2,3s, 3.4s, and 11.6s when all the selection is on an xz plane.
512K: 6.2s, 21s, 24s, 35s and 240s when all the selection is on an xz plane.

A few UV Editor results. As a reminder, 'kdTree' is this diff of set_prop_dist(...), 'N2' is the current single object set_prop_dist(...) and 'new N2' is diff at D5163 of set_prop_dist(...).

I didn't try selecting different vertices to see if it affects results.

I used a subdivided plane for my uv tests, the number of vertices in the UV Editor approaches four times that reported by the mesh. So the UV editor is handling nearly 128K vertices for the 32K mesh.

And a few 3D Viewport results.
kdTree timings dovary depending on which vertices are selected.

Thanks for the update, added to T63731, to review after 2.80 release.