Proof of concept: Use a single FilterEngine instance

This is a proof of concept I want to discuss, not code I want to commit.

It needs cleanup/refactoring, leaks memory and seems to hang on larger sites (e.g. heise.de).

But it generally works, e.g. here:
http://simple-adblock.com/faq/testing-your-adblocker/

Previously, each process had it's own FilterEngine instance. This is still the case, but FilterEngine::Matches() is now always called on the same instance, using IPC.

I'm using WM_COPYDATA for this because it seems to be the best approach without requiring admin rights, but the downside is that we have to do manual marshalling.

The marshalling should probably be more generic by allowing arbitrary data (not just strings) and prefixing each value with it's length (as opposed to using 0 as a delimiter).

What do you think, should we go ahead with this? The next thing I'll do is investigate why it's slow/hanging for larger sites.

[Oleksandr, 2013-05-04 02:40:02]

I am thinking it would indeed be too slow if we Marshall/Unmarshall and send
messages on EVERY call we need of FilterEngine. That's a lot of synchronisation
overhead on more or less big pages..


I guess I'm leaning towards Wladimir's view that DCOM would be best here :/
That, or using something like this:
about:reader?url=http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Faa366551(v%3Dvs.85).aspx&readingList=0&tabId=3

We can rewrite out FileSystem implementation and it would just expose one file
mapping for all instances. That way we'll get rid of constant "forgetting" of
the selected subscription. But I think this will still mean 1Mb worth of data
will be reparsed for every process.

I'll try to put together quick and dirty DCOM solution to see if that has any
bottlenecks.

[Felix Dahlke, 2013-05-04 02:49:46]

On 2013/05/04 02:40:02, Oleksandr wrote:
> I am thinking it would indeed be too slow if we Marshall/Unmarshall and send
> messages on EVERY call we need of FilterEngine. That's a lot of
synchronisation
> overhead on more or less big pages..
> 
> 
> I guess I'm leaning towards Wladimir's view that DCOM would be best here :/

How would that be any less overhead? DCOM needs to marshal/unmarshal every
message as well.

My only problem with DCOM is that it'd require admin rights during installation,
something I was hoping we could avoid sooner or later.

> That, or using something like this:
>
about:reader?url=http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Faa366551(v%3Dvs.85).aspx&readingList=0&tabId=3

Can't open that (assuming it's:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).asp...)

> We can rewrite out FileSystem implementation and it would just expose one file
> mapping for all instances. That way we'll get rid of constant "forgetting" of
> the selected subscription. But I think this will still mean 1Mb worth of data
> will be reparsed for every process.

You mean to work with one FilterEngine process per instance? We'd also have to
synchronise filters and subscriptions among all processes, that'd be a huge
effort. Not to mention that we're talking of about 40 MB of memory for each
process. I really don't think it's an option.

[Wladimir Palant, 2013-05-04 14:40:49]

I don't see why DCOM would mean less overhead, it's only a question of
complexity. Also, I'm not too worried about the message passing - we have that
in Chrome (implicitly, the browser does it) and the performance impact is
negligible.

[Oleksandr, 2013-05-04 15:01:37]

On 2013/05/04 14:40:49, Wladimir Palant wrote:
> I don't see why DCOM would mean less overhead, it's only a question of
> complexity. Also, I'm not too worried about the message passing - we have that
> in Chrome (implicitly, the browser does it) and the performance impact is
> negligible.
Message passing is exactly what I was concerned about. I have been trying to
find some benchmarks on that, since we will make quite a lot of calls to
FilterEngine. I did not find any, but if you say we can neglect that then I'm
fine with WM_COPYDATA as well. Still, I think it would be interesting to compare
the two approaches speed.. Matches() will slow down every request we detect. So
we should aim for the least possible footprint, I think.

[Wladimir Palant, 2013-05-05 10:33:18]

On 2013/05/04 15:01:37, Oleksandr wrote:
> Matches() will slow down every request we detect.

Performance of web request performance is typically network-bound, pretty much
never CPU-bound.