Multiprocess Firefox 44.b, Electrolysis Optimization
It so happened that Firefox uses a single-process model, and the reality is that such an approach, taking into account the dynamics of network development and partial connectivity with XUL, causes a lot of inconvenience, to say the least. One process has to process several threads, which greatly affects the performance of the browser as a whole. Responsiveness of Firefox left much to be desired, when the same Google Chrome perfectly rendered heavy pages, which had no effect on the performance of other tabs.
This state of affairs forced many to switch to chrome, and those who didn’t want to - searched for solutions in the form of various kinds of optimizations, which, in general, due to the illogical approach of the distribution of flows or the banal desire to set something on the blog simply exacerbated the situation. Now one process should not just work, but work very quickly! In the end, the developers themselves were well aware that one thing was not enough memory, another was low speed, which was basically justified by old bundles with XUL. In fact: we open several tabs in Firefox at once, we scroll them and at the moment of loading we see that everything is slowing down - there could be no talk of surfing.
Mozilla launched the Electrolysis project to adapt the Gekko engine to the use of several processes. What causes Mozilla to switch to a similar model for building its browser? First of all, it is performance and responsiveness. The main goal is to reduce javascript (jank), which manifests itself in standard operations - loading a particularly large page, typing in a web form or scrolling overloaded with page elements.
I propose to use the new features of the multiprocessor model (unfortunately, they are disabled by default, since they are still in development). All functions are checked by the author himself, and their values ​​are selected for the fastest and stable work. The main focus is on the performance and responsiveness of Firefox in the conditions of aggressive surfing. Memory consumption in comparison with the single-process mode should increase by about 12% -17% taking into account the forced use of hardware acceleration, and without it no more than 10%.
')
Since the project is only being developed and is not completely stable, edit it in the new profile and then compare the result. I consider it inappropriate to refer to my results because of the dampness of the project. The results simply can vary dramatically.
Warning. Applicable on all versions above 44 on the "beta" update channel. The fact is that part of the code of new functions simply will not be on Firefox with an update channel different from beta or developer, in order to preserve stability.
To change the update channel, you need to replace the string “realise” with “beta” in the channel-prefs.js file. The file is located in your folder: Firefox / defaults / pref
Possible incompatibility with some additions.
Rule about: config:
Remove the frame around the link during the click:
Protection
Devices
Disable hello
Firefox Ads and Snippets
Now the quality of work will increase significantly. Good luck.
This state of affairs forced many to switch to chrome, and those who didn’t want to - searched for solutions in the form of various kinds of optimizations, which, in general, due to the illogical approach of the distribution of flows or the banal desire to set something on the blog simply exacerbated the situation. Now one process should not just work, but work very quickly! In the end, the developers themselves were well aware that one thing was not enough memory, another was low speed, which was basically justified by old bundles with XUL. In fact: we open several tabs in Firefox at once, we scroll them and at the moment of loading we see that everything is slowing down - there could be no talk of surfing.
Mozilla launched the Electrolysis project to adapt the Gekko engine to the use of several processes. What causes Mozilla to switch to a similar model for building its browser? First of all, it is performance and responsiveness. The main goal is to reduce javascript (jank), which manifests itself in standard operations - loading a particularly large page, typing in a web form or scrolling overloaded with page elements.
I propose to use the new features of the multiprocessor model (unfortunately, they are disabled by default, since they are still in development). All functions are checked by the author himself, and their values ​​are selected for the fastest and stable work. The main focus is on the performance and responsiveness of Firefox in the conditions of aggressive surfing. Memory consumption in comparison with the single-process mode should increase by about 12% -17% taking into account the forced use of hardware acceleration, and without it no more than 10%.
')
Since the project is only being developed and is not completely stable, edit it in the new profile and then compare the result. I consider it inappropriate to refer to my results because of the dampness of the project. The results simply can vary dramatically.
Optimization
Applicable on all versions above 44betaWarning. Applicable on all versions above 44 on the "beta" update channel. The fact is that part of the code of new functions simply will not be on Firefox with an update channel different from beta or developer, in order to preserve stability.
To change the update channel, you need to replace the string “realise” with “beta” in the channel-prefs.js file. The file is located in your folder: Firefox / defaults / pref
Possible incompatibility with some additions.
Rule about: config:
browser.tabs.remote.autostart browser.tabs.remote.autostart.1 browser.tabs.remote.autostart.2 - true layers.async-pan-zoom.enabled - true dom.ipc.plugins.asyncInit - true (plugin asynchronous) javascript.options.asyncstack; true layers.acceleration.force-enabled = true (disable when problems with video) network.http.max-connections = 512 network.http.pipelining = true network.http.pipelining.aggressive = true network.http.pipelining.max-optimistic-requests = 32 network.http.pipelining.maxrequests = 96 network.http.pipelining.maxsize = 600000 network.http.pipelining.ssl = true network.http.proxy.pipelining = true browser.cache.use_new_backend - 1 (new caching system) memory.free_dirty_pages - true browser.tabs.animate = false image.cache.timeweight = 100 browser.display.show_image_placeholders - false nglayout.initialpaint.delay; 0 (create integer) browser.display.auto_quality_min_font_size - (-1)
Remove the frame around the link during the click:
browser.display.focus_ring_on_anything (Boolean) = false browser.display.focus_ring_width (Integer) = 0
Protection
network.dns.disableIPv6 - false network.dns.disablePrefetch - true network.predictor.enabled - false network.predictor.cleaned-up - true network.prefetch-next - false browser.send_pings - false network.http.speculative-parallel-limit - 0 (zero) privacy.trackingprotection.enabled; true (protection from bugs) browser.safebrowsing.enabled; false browser.safebrowsing.malware.enabled; false datareporting.healthreport.service.enabled; false browser.safebrowsing.downloads.remote.enabled; false extensions.blocklist.enabled - false extensions.getAddons.cache.enabled - false browser.chrome.toolbar_tips - false media.video_stats.enabled - false dom.battery.enabled - false media.peerconnection.enabled = false
Devices
dom.gamepad.enabled; false dom.vr.oculus.enabled; false dom.vibrator.enabled
Disable hello
loop.enabled; false
Firefox Ads and Snippets
browser.newtabpage.directory.ping - leave blank line browser.newtabpage.directory.source - leave blank line browser.aboutHomeSnippets.updateUrl - leave blank line
Now the quality of work will increase significantly. Good luck.
Source: https://habr.com/ru/post/276321/
All Articles