Loading…
[Firefox] Nightly flags uBlock running slow #824
9 participants
harshanvn
changed the title from [Probably Nothin] Firefox flags uBlock running slow to [Probably Nothing] Firefox flags uBlock running slow
harshanvn
changed the title from [Probably Nothing] Firefox flags uBlock running slow to [Probably Nothing] Firefox Nightly flags uBlock running slow
The only "uBlock" word in there is from that sentence:
I thought uBlock was supposed to be fast
What am I suppose to investigate?
Looking more in the thread, I don't know what I am suppose to investigate. I rather not spend limited time to try to guess. I need a precise issue and a URL.
If you see the screenshot attached to that post (link given below), it is flagging uBlock.
http://i.imgur.com/F52Rz9i.png
This functionality (to profile ad-don performance), and report if it affects Firefox performance. Here is the Bug related to it -
https://bugzilla.mozilla.org/show_bug.cgi?id=1071880
Obviously, this ad-don does not make Firefox slower at all. It makes it more responsive. However i thought you might want to look at the issue being flagged by the Firefox, just as FYI.
Ok, I use default-deny and I could not see there were embedded imgur in there.
Yes, no doubt a false positive, http://www.sueddeutsche.de/ loads very fast for me (with default settings). I don't know the technical details of that Firefox feature are, that sort of false positive would need to be investigated. Maybe uBlock was re-loading the filters following its auto-update, who knows.
Here is the first line statement in the bugzilla for the Addon Profiler (https://bugzilla.mozilla.org/show_bug.cgi?id=1071880)
It would be nice to identify add-ons that are causing jank because of their CPOW usage.
Looks like it is something related to Messaging part...
I am completely out of my domain here. Maybe @Deathamns pitch in here..
Here is the info. related to unsafe usage of CPOWs
Ok, An update from mozillazine forum
Wait, I thought uBlock was supposed to be fast?
It is. That figure the deem an addon to be "slow" is the amount of CPOW's it creates. uBlock is blazing fast, but creates a lot of these. I'd understand greasemonkey being slow, but not ublock...
Rough guess, but my understanding is that what is flagged is the time it took for uBlock's content script to receive an answer from uBlock's core when being asked (in a synchronous way?!) to retrieve relevant cosmetic filters for the page, as per result of the survey.
If I understand correctly, this is what feature 1071880 measure. Again, if I understand correctly, ABP will never receive that warning, not because it is faster, but because the injection of its gigantic stylesheet is not being measured by feature 1071880.
Now I will always be on the lookout to improve performance, but cosmetic filtering in uBlock has been pushed quite a lot, and it's unlikely there is much place for improvements anymore. I suppose eventually the message handling in Firefox framework will become fully asynchronous (like on Chromium) and there would be no longer such flagging. On Chromium, I believe uBlock's core and uBlock's content scripts are executed in parallel, as they are in different process, which is where Chromium shines.
Also, there are no details regarding the circumstances surrounding the warning. The page loads fast for me. How many filter lists were enabled (I've seen some users check all of them). Was uBlock in the middle of updating itself?
There are many things to look into, but certainly I cannot see the performance issue reported in there using FF35.
certainly I cannot see the performance issue reported in there using FF35.
This is in inbound Nightly build.
my understanding is that what is flagged is the time it took for uBlock's content script to receive an answer from uBlock's core when being asked (in a synchronous way?!)
This is my thinking too.
So, does Firefox does not have Async Messaging? And, i now wonder if the other branch, would eliminate Sync Messaging, and this feature would no longer flag?
Edit: I will install this ad-don in nightly (this feature will only land in Nightly 02172015 build, currently it is in hourly builds i believe) and will report if it triggers.
wonder if the other branch, would eliminate Sync Messaging
I had not seen this being worked on. I thought the sync was just a Firefox framework requirement. So yes, that would be nice if this can be avoided.
I just updated Nightly, and I started to see the notification. Synchronous messaging is used every time when a HTTP request happens (so basically just like in Safari, except there is no multi-process there), which is probably the cause of the complaint. Every other messaging is asynchronous.
In brief: this was the best way (that I could find) to properly support e10s. The tools they provide partially live in chrome process and partially in content process, so I tried to tie them with synchronous messaging.
I always knew this is not okay, but don't know any better. However, the only problem I encountered, is that using Firefox e10s enabled, when navigating to another page the page background turns white for a bit (for example, http://filehippo.com/, and click on the logo), which doesn't happen without µBlock or with ABP (but that doesn't seem to fully support e10s). This is why I started the nosync branch, but I faced too many problems that I don't know how to solve, so I iced it for a while.
every time when a request happens
Not sure how to understand this. "Request" as in "message with a callback"?
HTTP request.
Ok, but then that is the same on all platforms, it has to or else blocking would be completely unreliable.
Still not sure I understand fully: in uBlock, network requests are processed rather fast, so this can't be the problem. Is this because the network request is received in one process, but handled by uBlock's core code in another process, and so messaging must be used, and obviously synchronous messaging must be used because we have to determine whether to block or not the network requests? If so I would say it's the overhead of messaging which is the problem, as uBlock's filtering code is executed in a fraction of time it takes ABP to filter network requests.
So far, with all the bit of info I can piece together, to makes sense of this warning I quote the blog post:
there is the general IPC overhead
So given I have benchmarked that part of uBlock to know that its processing speed is a complete non-issue (it does better than pretty much everything else similar I've benchmarked -- ABP, AB, Ghostery), I am wondering here if in the end that Firefox notifier is simply notifying about the slowness introduced by the overhead of its own IPC code, but extensions end up taking the blame. If so, then I predict any Firefox extension which has for task to deal with every single network request is going to be flagged as a "slow" add-on. Web pages which fire a lot of network requests in a short time (like when loading a bloated page) are also probably typical cases where that notification is most likely to occur for such extensions.
So whether an add-on is deemed slow depends on how long between checks and the limit. A limit of 10s and an interval of 15s means an add-on must be using 66% of the time to warn. A limit of 10s and an interval of 30s means an addon only needs to use 33% of the time to warn
What are the default settings for browser.addon-watch.interval and browser.addon-watch.limit?
From the same thread:
Well, technically it's not the amount, but rather the time spent in those CPOWs (as said in the previous thread the threshold is 1% Usage per 120s = 1.2s CPOW-time in 120s).
At least now I know why I didn't switch to uBlock. I'd imagine an Add-On-Developer who writes a new Add-On would write modern asynchronous code and not use a "migration aid"[1] that has serious limitations and can cause performance problems.
[1] https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers
http://forums.mozillazine.org/viewtopic.php?p=14027939#p14027939
Is this because the network request is received in one process, but handled by uBlock's core code in another process...
Kind of. The request is received in both places. Content process is able to use ContentPolicy (the chrome process is not able to that with e10s), which collects the type of the request and sends it to the background page (which is in chrome process), also the tabId is determined with the help of the message.
Right after this message (and this is why it needs to be synchronous) happens a http-on-opening-request event (which cannot happen in content process), where we can modify headers, cancel request, or close tab...
What are the default settings for browser.addon-watch.interval and browser.addon-watch.limit ?
browser.addon-watch.interval;120000
browser.addon-watch.percentage-limit;1
I'd imagine an Add-On-Developer who writes a new Add-On would write modern asynchronous code
Receiving a network request and evaluating it asynchronously in order to tell the browser whether it should be blocked or not makes no sense if the browser framework is such that it needs an answer immediately upon reception of the request.
After the hostile reception with not a single technical comment about the benchmark but rather just assumption of bad faith on my person of how I ran the benchmark ("snake oil and horse feathers", "vested interest in fudging facts"), despite all the details and raw data being publicly available, I don't expect anything else than snide from that place.
The behaviour in that thread is baffling, but its good that we all have more information about all this now. Thank you.
@Deathamns commented on 17. Feb. 2015 16:58 MEZ:
In brief: this was the best way (that I could find) to properly support e10s. The tools they provide partially live in chrome process and partially in content process, so I tried to tie them with synchronous messaging.
@Deathamns commented on 17. Feb. 2015 18:22 MEZ:
Right after this message (and this is why it needs to be synchronous) happens a
http-on-opening-requestevent (which cannot happen in content process), where we can modify headers, cancel request, or close tab...
Could the request be suspended and asynchronously be resumed or canceled?
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/NsIRequest
So, if I've got this straight: nsIContentPolicy.shouldLoad gives you a whole bunch information you need in order to evaluate whether to block the request or not. There is no way to obtain all the necessary information from http-on-opening-request
In nsIContentPolicy.shouldLoad it is not possible to do anything that manipulates the browser itself, as it is in the content e10s process.
In order to communicate the information gathered from nsIContentPolicy.shouldLoad to http-on-opening-request a cross-process message must be passed, and http-on-opening-request must wait until it receives that message because it needs that information in order know whether to cancel the request or not. So the message must be synchronous. Firefox Nightly complains because it does not approve of synchronous messages.
Is that about the size of it?
I wonder, would it be possible to use the blocking facility inside nsIContentPolicy.shouldLoad rather than http-on-opening-request? If it's only the actual blocking of the request that needs to be synchronous, then all the other stuff that needs to be in the browser process (popup closing, UI updating, etc.) could be bundled off into a response to an async method. Of course the problem then becomes having to have the filter code and datastructures in the content e10s process rather than the browser one, which would no doubt be a complete pain.
Just a thought, anyway. All this e10s is still a bit of a mess, in my opinion, and it could well be that Firefox will simply stop complaining about this particular usage of synchronous messages in future builds.
@Yoyo117 That has no use, since the synchronous messaging happens even before the channel is created.
@AlexVallat Yeah, that's about it.
and http-on-opening-request must wait until it receives that message because it needs that information in order know whether to cancel the request or not
http-on-opening-request doesn't have to wait for anything, it just happens that http-on-opening-request follows shouldLoad, and if I would use asynchronous messaging, than the next http-on-opening-request may fire before the previous async message could arrive to the background page, so the information from shouldLoad couldn't be paired with the correct request.
shouldLoad could cancel the request (which would be better, because the browser in that case wouldn't even construct the http channels - actually this was the case with the early preview), but it can't redirect http requests (needed for local mirroring), also there was a crash which forced me to use sendRpcMessage instead of sendSyncMessage, but sendRpcMessage just sends a message, and can't give any answer back (meaning it can't tell if the request should be canceled or not).
to have the filter code and datastructures in the content e10s process
This is what I started in the the nosync branch.
I wanted to put the background script into a code module (basically shared memory) and load it in frameModule.js (so in every content process), so shouldLoad would be able to block requests, and even if synchronous messaging is required, then we would do it only for main_frame, sub_frame (for inline-script blocking), and for requests that are locally mirrored.
http-on-opening-request doesn't have to wait for anything
What I meant was that http-on-opening-request could occur before the async message from shouldLoad had arrived, and would therefore have to wait for it to arrive. Queuing and pairing could be probably be managed in some way, but if the details simply haven't arrived there yet at all, then it wouldn't be enough.
I will study your nosync branch when I get some time, I do think blocking in shouldLoad is a promising approach worth some investigation. You mention the problem with not being able to redirect, but looking at the current version of traffic.js it appears redirection is no longer being used...
it appears redirection is no longer being used
I disabled local mirroring since a while now, as there were many issues to address, all seemingly related to CORS. At the time I didn't have time to look into this, it's probably something that will need to be worked on a lot to figure what is safe to mirror. I say everything else has priority, so if in the end local mirroring doesn't fit in technically, well too bad, it was tried.
Just to chime in, don't take that notice too seriously, it flags pretty much 100% of the add-ons over time, even Mozilla's own "Add-on Compatibility Reporter" addon. 
a Blog Post regarding unsafe CPOW usage..
So, in nightly one would see this warnings iff e10's are enabled. It should not be any issue with non E10 mode (single process mode)..
However, i believe they are still cooking up Addon Profiler... about:compartments will give the details about CPOW usage, in e10 mode..
I didn't have e10s enabled, and got the notification...
That's strange. I am at office. So, cannot test right now.
When i tested yesterday -
With no e10, it did not shout at all. And if you go to the about:compartments, i saw 0ms spent in the 2nd column (CPOW usage)
With e10, it immediately reported for both noScript and uBlock. And i could see >0ms reported under 2nd column in about:compartments
I see 0μs in the CPOW column too, but it still alerts me.
By the way, I just tried with ABP, opened two pages (cnn videos, then filehippo), and got the notification.
Not sure for the difference in behavior, will try later tonight. I dont think it should matter if we are under non e10s mode. Isn't it?
And you are seeing >0ms when tested under e10s mode? I think this is where they are trying to eliminate. And explains it in the above post.
a Blog Post regarding unsafe CPOW usage..
Yes, I see greater than 0 values with e10s enabled (plus the notifications too), but so far I was testing and talking about e10s disabled.
Yeah, i got that. Just wanted to confirm! Thanks :)
The notification seems to be a new thing in firefox. I don't know how will they decide which ones slows down the browser and which not.
http://www.ghacks.net/2015/02/18/firefox-38-notifies-you-about-add-ons-that-slow-down-the-browser/
gorhill
changed the title from [Probably Nothing] Firefox Nightly flags uBlock running slow to [Firefox] Nightly flags uBlock running slow
Currently a Firefox issue, Firefox's notifier is too sensitive.
I saw an interesting post at mozillazine forums and thought, i would bring this to your attention sooner than later. At the below link, it shows uBlock making firefox slow. May be a false trigger in the new Firefox code?
http://forums.mozillazine.org/viewtopic.php?p=14027621#p14027621
Note: I am not the guy who reported it there. Just saw that and reported here..
If irrelevant, please close the issue. Sorry for the trouble.