←back to thread

Firefox 42 will not allow unsigned extensions

(wiki.mozilla.org)
288 points fernandotakai | 1 comments | 11 Aug 15 03:51 UTC | HN request time: 0s | source
Show context
ck2 ◴[11 Aug 15 10:19 UTC] No.10040018[source]▶
Between that and e10s being on by default, FF42 is going to go over like a lead balloon.

I hope 41 is an ESR

update, nope: only 38 and 45 are ESR

https://mozorg.cdn.mozilla.net/media/img/firefox/organizatio...

replies(1): >>10040537 #
shdon ◴[11 Aug 15 12:41 UTC] No.10040537[source]▶
What would be the problem with e10s? Sure, it's a big change, but it seems quite desirable imho.
replies(1): >>10040626 #
TheLoneWolfling ◴[11 Aug 15 12:59 UTC] No.10040626[source]▶
2-3x the memory use and lower performance due to the additional overhead of talking between processes.

There are advantages, but it is not without its disadvantages.

replies(1): >>10040674 #
shdon ◴[11 Aug 15 13:05 UTC] No.10040674[source]▶
https://wiki.mozilla.org/Electrolysis/Firefox

"Goals

There are number of things we believe the e10s project will give us:

...

2. Improved performance, especially on multi-core machines.

3. Better memory core stats."

That seems to directly contradict your concerns. However, these are stated goals and may not align with practical reality. I'd be surprised if, when these are numbers 2 and 3 on their list of priorities, the reality would be so very different.

replies(1): >>10040721 #
TheLoneWolfling ◴[11 Aug 15 13:13 UTC] No.10040721[source]▶
See https://news.ycombinator.com/item?id=9558745 (and actually the rest of that submission also)

Now, mind you, that was nearly 3 months ago. But the concerns there are still very relevant.

replies(1): >>10040818 #
shdon ◴[11 Aug 15 13:24 UTC] No.10040818[source]▶
Those 3 months can make a world of difference. I'd like to see it in action before I decide whether it is a good or a bad thing.

Also, I'd be very surprised if the numbers in this little test are more than anecdotal. Performance will depend heavily on the kind of content you're viewing and I'd wager that the IPC calls make up a very small minority of the runtime profile for a tab process. Also, not everything is so performance-critical. For instance, if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it? If everything in the browser just slowed down by a factor of 2, would Mozilla really ship it?

replies(1): >>10045589 #
TheLoneWolfling ◴[12 Aug 15 02:00 UTC] No.10045589[source]▶
> if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it?

Considering that a frame at 60fps is ~16.7ms, YES. That's 42% of your total frame budget!

And it's not just IPC calls, either. There are many things that are less efficient when you segment things between multiple processes.

Also, you're completely ignoring / missing the point of memory use. FF (or rather, Pale Moon) is currently using >1/4 of the RAM on my laptop. And swap is (really really really really really) slow.

replies(1): >>10047051 #
1. shdon ◴[12 Aug 15 10:43 UTC] No.10047051[source]▶
The exaggerated response time example was for a typical usecase. The amount of situations where there is actually 60fps rendering going on and necessary are few and far between. Most browser usage is of fairly static content. Especially in the case of a mouse click, when you expect something to change on the screen and almost everything in that change will depend on something much slower than the simple IPC call (if that even happens) of tranferring the mouse click event. Splitting things up between multiple processes can slow things down if done badly, and can also bring tremendous speedups if done right. I assume the folks at Mozilla know what they're doing.

And yes, I'm ignoring memory usage for now. Mostly because it is a horribly complex thing, especially in multi-process situations. The numbers are notoriously difficult to interpret between working set, commit charge, shared memory, memory mapped file IO. Unless you're actually debugging the code or an expert, it's basically just guesswork. Mozilla have improved Firefox's general memory footprint significantly these past few years and they're not going to throw those advancements away easily. Again, I trust them to know what they're doing.

As I said before, I'll reserve judgement on e10s until I get to experience it in daily use. All I will say in advance is that the premise and the stated goals make a lot of sense to me and it seems like a highly desirable technology.