The fact that Chromium runs multiple processes is unrelated to any field trials. Chromium has always been multi-process; that's why individual tabs and plugins can crash without taking down the whole browser. Additionally, multiple processes are needed in order to implement sandboxing on Linux.
Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in.... They are used to experiment with different solutions or, sometimes, to allow a change to be quickly reverted in the field if it's causing a problem. You can manually enable/disable several of these on chrome://flags/ (although it's not advised).
But that question doesn't make sense. It contains the assumption that the alternative would be to never ship broken features to users. While the actual alternative would be that they'd ship the same broken feature to all users. Because at some point there's no other testing left.
If they're shipping features that need testing, it seems like the Beta version is the right place to ship them, not the stable Chrome or Chromium build. As in: ship the possibly-broken features to people who have already opted into testing, and don't subject your users that chose the "stable" to random testing.
Getting the bad end of someone's unannounced feature testing is the kind of thing that makes me decide to use another browser for a few months, hoping that the problem disappears if/when I go back to it.
If they're not running new features through their Beta channel, then you have a point. Otherwise, I'd assume the features that make it to field trials have already gone through Beta testing and are thought to be ready to release--which isn't always the case, hence the gradual rollout.
I'd say that if they're doing A/B testing or "field trials", then they aren't sure enough to roll the feature out to Stable. That's not Google's policy, though.
I'm just grumpy that we don't live in the perfect world, where confusion-inducing processes like this wouldn't be necessary. I've never been that comfortable with the "break a few eggs" method of progress.
The piece seems to suggest that a) multiple processes were the performance problem and b) that a field trial was causing that and "mak[ing] my computer unusable".
Multiple processes do take more memory, but there's a good reason for them. While it's possible that it was a field trial that was causing issues here, there's no evidence to support that. Sadly, it was probably just excessive resource usage independent of any trials: Chromium did have a period where memory usage especially was allowed to drift and that was an oversight that Speed team are correcting (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/s...).
On the other hand, field trials produce important feedback. One example just from today: TLS 1.3 draft 18 had significant issues with middlebox bugs to the point where it wasn't viable to deploy it. Chromium has been using field trails to test variants of TLS 1.3 intended to work around these issues and allow TLS 1.3 to be used for real. This has resulted in concrete changes to help TLS 1.3: https://www.ietf.org/mail-archive/web/tls/current/msg24908.h...
These sorts of things require large-scale testing. We brought all the middleboxes that we could find for local testing, but that cannot account for the variety of firmware versions and configurations used in the wild.
The point of the post is that there is no way to opt out. We all understand more datapoints the better. But I also need to not be fucked with when I'm trying to work.
If you know the name of the field trial you should be able to opt-out on the command line provided you use the correct syntax with the --force-fieldtrials option.
However it was not established whether or not field trials (A-B testing) was even the problem merely that they existed on the chromium processes. Even the stable version of the browser will likely have these options on the command line.
> But I also need to not be fucked with when I'm trying to work.
But that's true of shipping any bug and isn't guaranteed to happen with a field trial any more than any new feature.
(and the OP doesn't seem to establish that it has anything to do with the field trial, just that the processes were run with that option? Admittedly I don't know how they actually work :)
I think the point is more about intentional performance degredation versus unintentional; it makes sense that you can't ship a 100% bug proof piece of relatively complex software, and some has to be patched out later, but such performance degredation or workflow interruptions can be planned for. But to intentionally enable an function which knowingly degrades performance or impedes workflows just for the sake of testing without the consent of the user is a bit rude. To repeat the author and other comments, if it were a beta-channel or test build where it was clear this was part of the intended functionality of the build, I don't think we'd be having this discussion.
Not to worry, chromium is open source. Just pop open a text editor and trace the code from the option parser to see where it's used. How hard can it be?
That TLS anecdote is pretty fascinating. Middleboxes are holding so much back on the internet. I wish the IETF didn't use such euphemisms as "middlebox robustness"!
I hope HN'ers push back against middleboxes at workplaces.
Multiple processes are used to implement sandboxing everywhere not just on Linux.
Just be careful with using chrome://flags to enable/disable certain things. First not everything will have an appropriate flags option. Second even if you enable/disable it in flags chrome may actually ignore it for certain things unless you actually force the field trial on the command line (I'm not sure how common this is).
Or just use Firefox, even if it is slightly slower than Chromium it's at least a browser that works for you not one that treats you as a pawn.
A Chrome monoculture is harmful, even if Google has the best intentions which I don't think they do - they definitely value their profits over an open web.
Funny thing is Firefox Quantum is both faster and eats less memory compared with Chrome.
>not one that treats you as a pawn.
And sadly, Firefox is the only browser that doesn't treat you like a pawn. For MS, Google, Apple, that chinese company which owns Opera you are just a pawn.
>And sadly, Firefox is the only browser that does this.
Not any more, I recently discovered that my firefox at work got infected with Firefox Pioneer. I didn't install that, it just appeared on list of my addons, no warning or anything. I heard on Reddit about similar cases from a few months ago, people got Safe Browsing installed without their knowledge. Both are signed addons from Mozilla.
Agreed 100%. I'd been using Firefox right since the early betas but at one point the scrolling performance grew so janky that I had to switch to Chrome. I hate the kind of bullshit chrome keeps pulling, specially the IE-like random standards that they keep inventing to make sure other browsers can't use certain features.
With quantum, Firefox is performing well. Even if chrome catches up I will not give up Firefox until it becomes so slow that I'm unable to use it normally. I don't care about the performance delta, just that it be good enough.
Inspired by this post installed Quantum beta and used it for the last few hours. Stuttering videos and subtly laggy typing. In what sense it is faster?
Its an alpha/beta, your experience is clearly a bug rather than the expected behavior. Personally my experience has been bug free but unfortunately obviously not all bugs have been squished.
I'm running nightly which in theory ought to have more chance at issues but more chances of fixes for said issues faster too.
> Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome.
Anecdotally.. Firefox was always slower rendering pages compared to other browsers. On some sites that I visited regularly, using FF was depressing. Later on, it started to suffer from caching issues on my machine. This caused a massive system slowdown.
Tried Palemoon (non-blink\webkit, etc). It blazed through pages- even the heavy ones FF had problems with historically. The rendered results were spot on too. It was like getting a new machine.
What I'm saying is that we can't blame everything on pages being optimized for Browser X or Browser Y. Sometimes we need to call out our favorite browsing application and let them know this is an issue. Otherwise, they keep losing users based solely on performance.
I'd check out the Firefox nightly which now has all the Quantum stuff - it's a lot better.
I also switched to chrome back when Firefox was a lot slower, but now I'm tempted to switch to Firefox or Safari and I try to occasionally.
I've historically had to switch back partly because I (stupidly) rely a lot on chrome's omnibox autofill memory and also because we use the switchyomega plugin at work and I don't want to deal with having a non-standard setup.
That is definitely not true. Firefox 57 is about as fast as chrome, and Firefox 59 may well overtake, but chrome has genuinely been faster than Firefox for a long time.
I don't really care that much about how many ms of difference there is in page rendering between the two but blocking UI is a different thing. Still in 56 with no legacy extensions UI blocks from time to time, switching between tabs is slower than in Chrome and scrolling blocks more often.
But if I understood correctly that could be finally fixed in upcoming releases.
1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.
2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.
3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.
4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.
5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.
That sort of thing.
Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...
A trivial example is that a 'for' loop vs. 'while' loop can be faster on one browser compared to another.
These differences are even starker if you use newer features without polyfills. For example, 'forEach' implementations as of a year ago varied by orders of magnitude.
Native array sorting is another obvious one. Chrome, Firefox and especially Safari use quite different algorithms each based on array size with varying results.
If you add up all those little changes and always go with the option that's fastest in Chromium, in a reasonably complex SPA you could easily generate noticeable differences.
If 'for' and 'while' loops vary in speed that much between browsers, isn't that a defect in the browser? If one way is faster in chrome than firefox, why doesn't firefox change how it is doing the slower version?
Because that would likely mean slowing down a different scenario. It's usually a trade-off, not a "defect".
The array sorting is a great example where the length of the array chosen or the pre-sort ordering can affect which browser is faster. No single browser may be able to claim the fastest for every scenario.
I don't write JS-heavy websites these days so I don't have a technical example to give, but for instance I've opened the Vue cinema website recently on Firefox mobile. The thing was unusable - when I typed my postcode, nothing would show up on screen, the whole website seemed frozen while waiting to load something. I had to press several times certain buttons for something to happen.
On Chrome however everything worked fine right away. Overall it was just a few images, some text and a search bar, so no matter the performances of the browser that should work everywhere, but since it was probably only tested on Chrome and Safari, it only worked in these browsers.
If most websites are faster on chrome than on firefox, why does it matter that the reason is people optimize for chrome? An end user doesn't care WHY chrome is faster, just that it is for their usage.
Same for me, I've also enabled all the experimental webrender flags on both private and work machines and have had basically no issues at all for the last weeks.
It's actually almost slightly uncanny how well it's working.
This might be a placebo effect, because last I heard enabling WebRender would leave the usual renderer enabled as well in order to paper over yet-unimplemented features, which should often result in double the work and, one would assume, worse performance. But if it doesn't feel slower, then, well, that might be some kind of triumph. :P
I'm still on chrome, because of pepper flash.. :/
and because debugging angular sucks on firefox.
Edit: still checking out if it might be possible. i've just seen that the newer firefox has also some kind of flash player integrated. just the debugging is now strange.
Firefox is not immune to this behavior.
Please look up the preference "experiments.enabled" before recommending blindly.
In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years, a direction I'm really not happy with.
The main difference is that Firefox still gives you pretty liberal access to most internal settings, while Chromium is abysmal, if not ridiculous.
I'm talking about A/B testing internal features exactly like Chrome, such as ip v4/v6 path preference, pipelining support, TLS faststart (and so on) according to a random cohort selection.
While you can certainly turn off these sorts of features, I just want to emphasize that these are intended to make the product better, and Mozilla abides by a fairly strict privacy policy (when comparing to most tech companies at least):
The intention is to ship features that people actually want, and to ensure that Firefox is actually working for people (not everyone can/will file bug reports or post on twitter or hackernews etc)
can we set experiments.enabled to false? if so that's a severe difference, albeit a questionable default, there should be a popup on install, or at least a message on install
The extension API change has been widely available information for ages now, with a significant migration period. If an extension developer chooses to not update their extensions, that's their choice.
It is impossible to update a gesture extension into something that works properly. The APIs don't exist. The workaround is to inject scripts into the page to track gestures, which means gestures don't work until the DOM is parsed, and don't work on about:newtab or other about pages.
Multiprocess had a significant migration period. Webextensions had "Well here's some APIs, we'll try to get you more before the day we switch. Some of the important ones are coming the version after, oops. And some are still missing but suck it up."
Would the author be happier if Chrome/Chromium didn't do these "field trials", and instead just enabled whatever feature they were testing for all users, and the author was hit with the same problem, along with everyone else?
When you cut through the rhetorics, the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The alternative is millions using browsers ridden with last year's vulnerabilities.)
>the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The alternative is millions using browsers ridden with last year's vulnerabilities.)
You're misrepresenting mandatory enrolment in A/B testing with plain software updates. Firefox is an example of a browser that does software updates, but does not force you to use potentially buggy features - and yet they do not have "millions using browsers ridden with last year's vulnerabilities", because their alternative is to give users a choice to enroll in experiments. I do participate in experiments since I wish to improve Firefox, but I could switch to any time to no experiments at all.
A/B testing is not some nefarious scheme to harm users. When Google or Mozilla wants to add a new feature, there are basically three choices:
(1) Opt-in: Add the feature to the new version. Users must choose to upgrade.
(2) Opt-out: Roll out the new version automatically, unless the user actively choose not to.
(2a) Opt-out with A/B test: Roll out the new version to a small portion of users first, and proceed if nobody catches fire.
Once you decided to use opt-out, there aren't that much difference between (2) and (2a). The major difference is that with (2a), a smaller number of users are hit when an unforeseen bug inevitably finds itself into release process.
And of course we know what happens when something like a web browser relies on the users to actively click "Upgrade". I'm sure there are some people still using IE6.
All features are potentially buggy. There's no particular reason to allow users to opt out from trials, same as there's no reason to allow opt out from upgrades. The chance that you will be impacted negatively is minimal.
1. I'm not seeing the causal link between the flag and the symptoms. I often find "Chrome" "causing" the same problems, but typically you can judge from the memory use that an errant tab is allocating the world, and you've started drawing on swap, which of course slows things down. But here we've cropped the memory stats out of the screenshot from top (for the system as a whole; we can see a few processes consuming a few hundred MiB, but Chrome loves processes, and there could be several more below, and summing RAM usage from processes is a deceptively tricky beast), and I can see nothing to prove that the field trial is even to blame.
2. You get the browser for free. If everyone adopted this same attitude, Chrome would not be able to do real-world A/B testing on features; what should they do instead, just release it all or nothing? You might have been unlucky today, but perhaps tomorrow someone else's misery provides the needed data to prevent a bad feature from going out.
3. Vote with your "feet", and switch to Firefox? (or one of the other myriad of browsers out there…)
Regarding point 2: what if Tesla pushed silent OTA updates for A/B test that accidentally disabled ABS or traction control, rendering the car unusable?
This is what I cannot grasp about modern software project management/ops. <s> The only relevant measure is time to ship. If the unit tests pass it is good to go. </s> So many times have I seen webapps so broken that core functions do not even load or by no means would pass simple "click here and there" usability test. In house QA sometimes seems to be abandoned. Automated testing is a good thing, but in my book shipping comes with implicit assertion that changes perform the task at least on a basic level.
Field A/B testing of experimental features is a good thing, which I am ok with even if I happen to get worse alternative. Shipping outright broken features if I am not on beta/testing/nightly release channel is unacceptable.
Blink (Chromium’s engine) was forked from WebKit (Safari’s Engine) and the two have developed separately. Safari is not a skin of Chromium or vice versa.
> Hopefully Mozilla has done a quite impressive work on Firefox those past few months and I personally don't see any advantages anymore for Chrome.
I use nightly and it is pretty good. Quite a few things are broken in nightly in Android but I can use nightly as my main browser (besides for hangouts which Google has yet to implement). Edit, we have pocket on Firefox though so https://getpocket.com/blog/
Yet, even though it affects only a super small set of users, it's still a ridiculous thing for Firefox to do.
From the article: "One of Mozilla’s core privacy principles is No Surprises: we will use and share data in ways that are transparent and benefit our users. That is why we are telling you about this today. "
Which doesn't make sense. If one of your core privacy principles is to tell your users what you're using & collecting, why not just tell them before/while downloading? Or better yet, let this be opt-in?
This isn't big enough of a mishap for "the love" to be misplaced, but it is enough to always be wary of what even the most privacy-minded companies do with their products.
For a developer there is no better browser than Firefox Developer Edition 58+ at the moment, its new Quantum engine is insanely fast and the included developers tools are far superior than the ones on Chrome.
I know Firefox had a dark period on which it felt behind Chrome on most fronts, but those days are over, if you haven't used it on a while, give it try! you won regret it.
Iridium's stable release is based on Chromium v61 and Chrome is on v62. Sure they can boast about enhanced privacy, but I'm not so sure about security unless their base Chromium version is always up to date.
Chrome honestly hasn't improved much in a while. It's kind of like where Firefox was back in 2012. Now that Firefox is faster and more efficient, maybe they'll start putting more effort back into it.
What happened to "Don't be evil?". Or they changed it to "Do not eval?":D.
Bit off topic, but that guy experienced lagginess in UI due some rogue Chrome process. I remember some bug in VLC that slow down my computer to level, it was not even possible to type on keyboard.
And I wonder, why is this happening in era of multicore CPUs? Why there is no restriction (by default) for process, how many cores it can utilise? I mean the tooling is already there (cgroups on Linux), but they're not used by default.
Isn't the answer here to just run the latest stable version where the impact of field trials would be minimized? Even the stable version will probably have features/field trials in the command line if you start looking at it for render processes. It was also never established if this A-B testing through field trials was to blame. It is a valid way to roll out new features to users while trying to minimize breakage. Most of the unstable stuff happens with the unstable branches in any case (dev and to a lesser extent beta).
I do realize this isn't the best answer but I thought that the closer you get to canary/dev branch the more variation you'll be subject to. You can force field trials on and off at the command line if you know the option name and how to format it correctly.
The author assumes that the field trial command line arguments are somehow related to the issue he had, which is not the case.
Chrome is always running multiple processes and they always have a very large number of arguments, including field trials. He's just describing normal behavior.
I’d appreciate a curated list of software vendors who don’t run these kind of field tests/experiment/whatever on their users. Extra points if their products are not filled with bloated “”””analytics”””” crapware either.
The funny thing is that it is not difficult to prove the exact cause with a debugger and symbols in cases like this either. I wonder if doing what Process Explorer does (quickly suspend/resume threads and display call stack) would be easy in Linux though.
Shameless plug, my browser is: https://cretz.github.io/doogie/. I do no telemetry, surprise feature testing, etc. There are of course others, the best of which is Ungoogled Chromium, but they are a bit behind on their updates.
The Iridium website and logo look so professional and "enterprisey" that it looks like there's lots of money behind of it and they're going to screw you. A barebones or even text-only website would do them a favour.
I think it just needs minor tweaks. I would replace the marquee with static text and replace the section title "Manifest" with something clearer like "Our Purpose" or "Our Ambition".
Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in.... They are used to experiment with different solutions or, sometimes, to allow a change to be quickly reverted in the field if it's causing a problem. You can manually enable/disable several of these on chrome://flags/ (although it's not advised).