RobRich999 / Chromium_Clang

Chromium browser compiled with the Clang/LLVM compiler.
157 stars 10 forks source link

Benchmarking #31

Closed etiennemlb closed 1 year ago

etiennemlb commented 1 year ago

Enabling some compiler switches is great I suppose but could you provide or recommend some performance comparions with a typical sse3 build. Else, where should I expect gains/loses.

RobRich999 commented 1 year ago

Multiple users and I have done numerous rounds of testing over the years, though much of the public testing is interspersed through thousands of other comments at Jerry's site. It is not ideal for research long after the fact, but "it is what it is."

https://chromium.woolyss.com/?all=1#comments

I do not compile and maintain public benchmark logs, but I rarely bother with LLVM passes and other optimizations if there is no particular benefit, as otherwise they tend to simply increase already long build times. I can say it that I have been experimenting with numerous Chromium optimizations for several years, even long before my GitHub repo, going back to even the Visual Studio days of Windows builds. I have probably done (tens of?) thousands of internal builds just in iterative internal testing to derive my build configurations. I used to be way more involved, but admittedly, these days not as much due to personal issues among other things.

Realistically, do not expect massive differences, but the reality is usually at least a few percent gains in most common browser benchmarks. Some benchmarks can benefit by several to perhaps even many percent, though differences can be subject to other factors related to system hardware, operating system, driver revisions, and more. What benefits one config might not benefit another, thus my usual YMMV disclaimer and why end-users should ideally run their own tests.

https://en.wikipedia.org/wiki/Browser_speed_test

Some aspects will be more difficult to measure, too. For a quick example, in my experience Polly optimizations often can benefit multimedia components due to the underlying code typically being quite loop intensive. That is an example where it might not be a clear benchmark number, but more like hopefully improving processor utilization numbers.