Hi Fedorans, Here's the situation:
Recently, someone filed a bug against chromium, noting that it was benchmarking notably slower than Google Chrome or chromium-freeworld (from rpmfusion). I tested locally and confirmed it. They suspected that Fedora's optflags were to blame, but since chromium doesn't use them anymore, that wasn't it. chromium-freeworld enables some media codecs we cannot, but this shouldn't affect javascript benchmark tests. VAAPI is turned on in both builds, but not in Google Chrome. Ultimately, the culprit was in how chromium is built for Fedora. There are two ways to build chromium: as a giant static binary (which is how Google Chrome and chromium-freeworld are built) and as a collection of shared libraries (which is how Fedora's chromium is built). I did a test build of a static version of Fedora's chromium and the benchmark performance went up to expected levels. It's worth noting that IMHO, the performance loss is noticeable, but the browser is still usable. So, you might be asking, why does Fedora build in shared mode? There are two main reasons: 1) To enable users to be able to swap out the media components from Fedora with a "freeworld" version. 2) To keep the size down on the chrome-remote-desktop subpackage (since it can share the "internal libs" from chromium). Switching to static mode gives us: 1) Fully working krb5 (because it would resolve the symbol clash caused by the use of chromium's boringssl fork). This bug has been outstanding for a few years now. 2) Performance improvements. HOWEVER, switching to static mode means that: A) It will become impossible to have an addon package from rpmfusion (or wherever) to swap in the additional media codecs we cannot include in Fedora. The only way to get those codecs would be to install an alternate build of chromium (chromium-freeworld) or a different browser (Fedora). Hypothetically, it might be possible to try to patch chromium to build _just_ the media bits as a shared library (or to have it dlopen them), but upstream is not in the slightest way interested in that, and untangling the Lovecraftian nightmare that is the custom Chromium buildsystem is not my idea of a fun quarantine activity. Full disclosure here: rpmfusion has not really been doing builds of this addon package (chromium-libs-media-freeworld) for quite some time now. I'm not sure why. This means that at least for the last few months, this option hasn't really been available to anyone outside of people doing manual rebuilds of the chromium SRPM with the %freeworld and %shared variables enabled. B) Per process memory utilization for chromium might go up. Not sure about this. C) Chromium's build process gets...angrier. Still doable, but you have to do things like set ulimit -n 4096. (Fun fact: the man page section for ulimit says that for -n, "most systems do not allow this value to be set". Guess modern Linux isn't most systems.) Now, we could make a chromium-static subpackage (just 4-6 more hours added to the koji build), but I'm concerned that users would not understand the purpose of it, and even if they did, they'd get unhappy when they discovered that it had missing codecs. There are a large number of web services that convert GIF animations to embedded videos these days, and most of them aren't using codecs we can ship (hi Twitter). This is my dilemma. (It is not my only dilemma, nor my most pressing, but it is still mine.) That said, I would love to get input from other smart Fedorans as to what I should do here. Thanks, Tom
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
