Going to mark this P3 right now because I don't have cycles to dive in atm. In terms of bang-for-our-buck, as Mike and Florian have said, optimizing lookups here is going to be our best bet. The only other thing I'd say is that it looks like we hit this for the `_onUpdate` handler, which means clients will hit this whenever a blocklist update is pushed. As Mike said, it's no worse than before because the XML list did the same, but it's worth bearing in mind... Additionally, for the remote settings backend, we could try to make the update handling smarter. Remote Settings tells us which records are new, modified or removed, and we could use those to limit the processing - ie we could only check whether the changed items match already-installed add-ons. Finally, we could try excepting builtin add-ons from the blocklist, but that'd probably require some discussion with the AMO folks as to whether that's a reasonable thing to do. Given that the AMO change should allow us to make these lookups take less than 1ms, I'm not sure it's worth going down those routes at the moment, when it looks like the blocklist AMO changes are coming in Q1 anyway.
Bug 1602099 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Going to mark this P3 right now because I don't have cycles to dive in atm. In terms of bang-for-our-buck, as Mike and Florian have said, optimizing lookups here is going to be our best bet. The only other thing I'd say is that it looks like we hit this for the `_onUpdate` handler, which means clients will hit this whenever a blocklist update is pushed. As Mike said, it's no worse than before because the XML list did the same, but it's worth bearing in mind... Additionally, for the remote settings backend, we could try to make the update handling smarter. Remote Settings tells us which records are new, modified or removed, and we could use those to limit the processing - ie we could only check whether the changed items match already-installed add-ons (rather than re-checking against older, non-modified items, too). Finally, we could try excepting builtin add-ons from the blocklist, but that'd probably require some discussion with the AMO folks as to whether that's a reasonable thing to do. Given that the AMO change should allow us to make these lookups take less than 1ms, I'm not sure it's worth going down those routes at the moment, when it looks like the blocklist AMO changes are coming in Q1 anyway.