Thorium – The first browser to score over 600 speedometer points on a Mac M3 Pro
github.com
github.com
I can't speak for blink/chromium, but as I spent most of a decade working on webkit and JSC, there are lots of trade offs for performance that can heavily benefit benchmarks without benefitting real web content.
* First off PGO. You have to be very careful when you do profile guided optimization as you _could_ simply do nothing but do the profiling passes on benchmarks, but if you aren't testing actual web content you can pessimize actual page load performance (speedometer tries to be better at general browser perf than older benchmarks but you easily fall into a trap equivalent to making your browser the fastest at loading gmail but slower at yahoo mail :D)
* A lot of modern browser performance comes as a result of caching policy, not in the download sense, but internal data structures. For example many years ago when I implemented bytecode caching in JSC (literally JS string source->bytecode) which saves you parsing and codegen time, but uses a lot of memory. A lot of the qualification for enabling that was "how much memory should be willing to burn in exchange for this performance", how time sensitive should the cache be, etc. Similarly you can get significant performance wins by making the GC heap large enough that you avoid sweeping during a benchmark.
* Browsers also do a lot of event coalescing to try and minimize unnecessary dispatch costs, relayout, and repainting. You can generally adjust the coalescing policies and you can get good "performance" wins by increasing the coalescing windows, but the result can be perceivable lagginess and similar, but again it will help "performance" as measure by wall clock.
It should not be a surprise that you can configure a chromium build (or gecko, or webkit) that can "out perform" the default configuration at some [set of] benchmark[s], but you should ask yourself why in a field as performance sensitive as browser and js engines the developers aren't already doing what you've done, and maybe the result of your changes is actually lower overall performance or otherwise worse user experience.
Of course you should, but you should also play around with the settings and publish your findings. If we didn't explore we wouldn't learn anything. It's possible that those other developers simply didn't consider a setting important, or that what they consider normal browser usage isn't the actually common case.
We should encourage experimentation of all kinds.
Even if the user were aware of all the same facts and had all the same understanding as the developer. Even while working on open source code.
About three weeks earlier, the team was celebrating wrapping up a release at a reasonable hour (for once) when I uttered the words, “You know, this is the last release we are putting out before April Fools’ day.”
Everyone in earshot somehow thought this was a tremendously valid point. By 1:00 am there was not one but around five separate Easter eggs set to go off on April 1.
You will note I said April 2 above. I sat with the lead dev as we verified how date and time offsets worked so we didn’t have any off by one errors. Seems that some fields were zero indexed while others were one indexed. Terrible MS API. We came to consensus on what was right, we may have even tested it, and I left.
But unfortunately he had a crisis of faith an hour later and created the off by one error. Luckily for us April 1 that year was a Saturday. A lot of our users, who had internet at work, never saw the prank at all, even with the off by one error.
On Sunday the tech support emails started rolling in, and our clever little joke started to reveal itself as poor judgement. Some people got the joke, but many thought we had been hacked. By Monday we had a canned response, apologizing for our bad judgement and anyone who got freaked out thinking they got a virus, or that we did.
Three proper adults and three college seniors and nobody said stop.
I'm not able to decipher what went wrong from your comment right now (though it might just be me!).
The jokes were some ui changes. The icon spinning backward and the progress bar saying April Fool’s in rainbow text every nth page load. A bouncing logo screen saver like behavior that would wipe a window that had been idle for X minutes (restored on mouse over).
I think there was one more, but the last I remember was the lead’s idea. After four (1?) hours idle, if you had audio enabled, you would hear the lead rapping his knuckles on his monitor and saying, “Hello? Is anybody there?” That could be funny or it could be terrifying.
That would definitely be funny. But people are more uptight these days (or maybe they always were).
Well, since this story is from 1995, so allmost 30 years ago, I think people are still as uptight today, when you compare it to this easter egg.
I didn't do anything but repost the bold link from the first paragraph of TFA...
I'm just happy some people are keeping the yiff community in mind :)
Maybe parent your children so when they go digging around in open source code and find some furry art it doesn't somehow destroy them.
Single-developer projects are always risky. What if the dev just decides to stop developing it? Or there's a massive vulnerability, and they're on vacation with no internet?
maybe the point of publishing the work on a new browser like this is to get the word out, get folks to fool around with it and explore the changes, and hopefully perhaps assemble a small community capable of seeing through a vision of making a faster chromium, rather than getting folks blindly using it as their daily browser straight away?
if the project does take off, by the time it is actually good to be used as a daily driver it will be void of any furry art, trust me.
the beauty of open source is that if the original developer stops developing or goes on holiday for a year you can pick up the torch. mature projects are eventually smooth-sailing and can be used out of the box, but any project goes through many years of not being so pleasant to use (most of the time, the reason's very simple: nobody's getting paid to work on it, so be grateful you have the software in the first place!)