[experiment] Issue 7045 - Optimize V8 memory layout of filter text

This patch reduces the initial memory footprint by ~3.8 MB on V8 by optimizing the memory layout of filter text containing very long (1,000+ characters) domains.

To test this patch:

 1.  Do a fresh install of ABP built from source, let the first-run page open up, open Task Manager in Chrome and close all tabs
 2.  Rebuild from source, wait for the extension to load, wait a few seconds for GC to kick in, and observe the "live" JavaScript memory in Task Manager
 3.  Apply the patch and repeat step 2

In step 2, the memory used (heap) should be ~40,500 KB. In step 3, it should be down to ~36,500 KB.

[Manish Jethani, 2018-10-15 21:52:49]

Patch Sets 1-3

This patch is black magic, but if you apply it you'll find that it reduces the
initial heap size by ~3.8 MB.

In terms of performance, it seems to slow down `Filter.fromText` for the loading
of the default subscriptions (measured in `lib/iniParser.js`) by about 10-15%.

[hub, 2018-10-16 15:30:19]

My concern here is this change that is across platforms is made with v8
internals in mind. What effect does it have on SpiderMonkey (Gecko/Firefox)?

[Manish Jethani, 2018-10-16 20:02:07]

On 2018/10/16 15:30:19, hub wrote:
> My concern here is this change that is across platforms is made with v8
> internals in mind. What effect does it have on SpiderMonkey (Gecko/Firefox)?

Alright, so I built the extension for Firefox, loaded it in the browser, and
played around a bit. Of course it works just like before.

Then I tried to check the impact of the patch on memory usage. In order to do
this, you have to open the developer tools for the background page, go to the
settings and click the "Performance" checkbox, which will make the Performance
tab appear, open the settings for the Performance tab (it has its own settings
drop-down menu) and enable "Record Memory", which is clearly marked as an
experimental feature. I did this, and then reloaded the extension and measured
the "performance" (which includes memory). I found that the memory settled at
~39.5 MB before the patch and ~41 MB after the patch. I tried this a couple of
times to make sure, and yes indeed this patch increases the initial memory
footprint on Firefox. Peak memory too is higher at ~97 MB vs. ~83 MB. I think
that is all fine, we're primarily interested in V8 anyway.

Regarding the performance of the `Filter.fromText` function before and after the
patch: inexplicably it seems to perform better after the patch. I don't know
what's going on, but I don't trust the numbers in that profiler because the
"self time" and "total time" (time in the function body and total time,
including time in all the functions that it calls into, respectively) are
identical, which is simply not possible. I really cannot conclude anything about
performance from this.

In any case, it looks like the extension is working properly after the patch, it
seems to take at most a couple of MB more (which is fine on the desktop), and
the question of the performance of the `Filter.fromText` function is up in the
air. I have no reason to believe that this patch is bad for Firefox. Given that
our target is primarily V8 for these kinds of optimizations (for
libadblockplus), it should be OK.

We could test on Edge as well, but I expect that we would see similar results.

[Manish Jethani, 2018-10-16 20:09:28]

On 2018/10/16 20:02:07, Manish Jethani wrote:
> Peak memory too is higher at ~97 MB vs. ~83 MB.

Since peak memory has come up, I just looked at the peak memory on Chrome (the
maximum value before it drops after garbage collection). It's like 3-5 MB lower
(it varies) after the patch.

[Manish Jethani, 2018-10-21 13:22:45]

There is another way to do this that might be cleaner and have benefits on
Firefox as well, let me try it out.