This is about the setting "Hide placeholders of blocked elements" (enabled by default).

Key observation: most images are not blocked by uBO with default settings/lists. This means the need to collapse images on a page is uncommon.

Case: https://en.wikipedia.org/wiki/List_of_country_calling_codes

The page contains 343 <img> tags, which causes 261 distinct network requests to be fired.

Roughly, this is how it worked before the fix here:

1. uBO's main process filters the 261 distinct network requests.
   • The result of each of these requests is stored in a short-term cache.
   • So 261 entries are added to the short-term cache.
2. uBO's content process scan the page for collapsible elements.
   • The result is the collation of 343 images which may need to be collapsed.
   • For each of these collated images, an entry is created which contains the URL of the image.
   • The 343 entries are sent to uBO's main process for evaluation.
3. uBO's main process receives the collection of 343 entries from the content process.
   • Each of the 343 entries must be evaluated to find out whether they were blocked, and hence whether they need to be collapsed.
     • Fortunately, the short-term cache contains the result already, so it's merely a lookup operation.
   • Once all the 343 entries have been iterated, the result is sent back to the content process.
4. uBO's content process receives the result of it previous requests, 343 entries, each containing information as to whether it must be collapsed or not.
   • All the entries are iterated, and for those marked with "collapsed", the associated DOM element is visually removed from view.
   • For the specific test case at hand, none of the 343 entries are marked as "collapsed", because none were blocked.

Roughly this is how it works now -- I reproduce the above steps, and will strike out what no longer occurs, with a note aside explaining what occurs now:

1. uBO's main process filters the 261 distinct network requests.
   • The result of each of these requests is stored in a short-term cache. The short-term cache is now used only for blocked requests.
   • So 261 entries are added to the short-term cache. No requests were blocked, so the short-term cache is now empty.
2. uBO's content process scan the page for collapsible elements.
   • The result is the collation of 343 images which may need to be collapsed.
   • For each of these collated images, an entry is created which contains the URL of the image.
   • The 343 entries are sent to uBO's main process for evaluation. no entries are sent, uBO now merely query the main process for a list of requests which were blocked.
3. uBO's main process receives the collection of 343 entries from the content process. uBO's main process receives a query to send a list of network requests which were blocked.
   • Each of the 343 entries must be evaluated to find out whether they were blocked, and hence whether they need to be collapsed. The short term cache contains what was blocked, so the content of the short term cache can just be sent virtually as is.
     • Fortunately, the short-term cache contains the result already, so it's merely a lookup operation.
   • Once all the 343 entries have been iterated, the result is sent back to the content process. Nothing was blocked, so the short-term cache is empty, so an empty collection is sent back to the content process.
4. uBO's content process receives the result of it previous requests, 343 entries, each containing information as to whether it must be collapsed or not. uBO's content process receives a collection of what needs to be collapsed, so an empty collection in the current case.
   • All the entries are iterated, and for those marked with "collapsed", the associated DOM element is visually removed from view.
     • One of two code paths is taken:
       1. The returned collection is empty -- i.e. nothing to collapsed a.k.a. no-op.
       2. The returned collection is not empty, there are DOM elements to collapse, so uBO will iterate trough the collated elements in step 2 and extract the URL to find out if it matches any entry in the list of blocked requests returned by the content process.
   • For the specific test case at hand, none of the 343 entries are marked as "collapsed", because none were blocked. For the specific test case at hand, nothing was returned, so it's just a no-op.

All the stricken parts above is the overhead which is removed by the fix here.