Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Why browsers are bloated

Name: Anonymous 2014-07-27 0:20

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/Scrollbar.cpp
https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
Let's reinvent the fucking scrollbar, which every goddamn platform with a UI already has, and make it behave subtly different from the native one!

Right-click a native scrollbar in some other app:
- Scroll Here
- Top
- Bottom
- Page Up
- Page Down
- Scroll Up
- Scroll Down

Right-click a scrollbar in Chrome:
- Back
- Forward
- Reload
- Save As...
...

Right-click a scrollbar in Firefox and Opera:
Absolutely fucking nothing happens!

What the fuck!? How did these terminally retarded idiots get involved in creating one of the most important pieces of software to the average user?

Name: Cudder !cXCudderUE 2016-03-13 1:21

Larger code is VERY often faster
You obviously don't know what a cache is. Loop unrolling and similar bloating "optimisations" are dead, they died a decade ago along with RISC, ultra-high clock speeds, and long pipelines.

I have posted benchmarks above in >>131. The tokeniser takes around 20 clock cycles per input byte on average and that's including all the processing to determine tags and attributes. There is no fucking way his tokeniser can do better than that - the overhead of all the unnecessary instructions introduced by manually keeping track of state and calling functions (through a pretty unpredictable indirect call) and accessing and allocating memory when it doesn't need to is going to slow things down significantly. Looking at the benchmark you can see the slowest part is the tree construction, which is - currently - in C, and does do the stupid one-function-per-state thing, but that's just because I wanted to quickly get something working, and never got around to rewriting it better/examining the spec more closely to find what could be simplified.

Newer Posts