Pre-filter sources for queryRenderFeatures

[anandthakker]

This change aims to improve queryRenderedFeatures performance in cases where a layers parameter is present by only querying the sources referenced by the requested layers.

This can lead to significant savings in some cases because (a) the first time a newly-loaded source tile is queried, it must parse the pbf data into a VectorTile, and (b) tiles for some sources may be reloaded quite often if, for instance, setFilter or setData are being used for "hover"-like interactivity. (See also #2874)

[mourner]

Nice! Let's fix the build.

[anandthakker]

^ last commit should fix the build and adds a test of the new behavior

[anandthakker]

@mourner @lucaswoj this is ready for 👀 now.

(Also, I apologize for creating extra noise over in the feature-id-shader ticket)

[lucaswoj]

Do you think we could get by with a simpler implementation like this 👇 ?

for (var id in this.sources) {
    if (!params.layers) continue;
    if (params.layers.some(function(layerId) { return this._layers[layerId].source === id; }) continue;
    ...

[anandthakker]

Sure, 👍 for filtering the sources within the loop like you propose.

I'm a little bit wary of using array.some() here rather than a plain for loop over params.layers, only because this method could get called with a pretty high frequency, e.g., in a mousemove. handler, where this might make a difference. (But I admit this is based on intuition, not quantitative evidence)

[lucaswoj]

I don't think the impact of Array.some or equivalent logic will ever be a bottleneck next to Source#queryRenderedFeatures. If it becomes one, we will identify it in the profiler and look for optimizations.

[anandthakker]

Heh, fair enough 😄

[anandthakker]

@lucaswoj ^ simplified the logic -- I did it this way because the "no-loop-func" linter rule prohibited the particular form you suggested

[mourner]

Given that we're dealing with sources, the difference between discussed forms will be negligible because there are typically only a very few sources on a particular map. However, in other situations like this where there are more objects to deal with (like layers), the original form with a simple for loop and a hash is highly preferable because it's O(n) rather than O(n^2).

[lucaswoj]

If we can't do the O(n^2) logic as a one-liner, we should revert to the O(n) logic. I pushed a commit that implements this. We can merge on 🍏