Why browsers are bloated

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?

>>120

C64 democoder why she

This contradiction is bothering me.

This thread most likely to be voted Thread Of The Year (TOTY).

Benchmarked the parser against Chrome and... it's ~50% faster. I wasn't even optimising for speed, only size (it is at least an order of magnitude smaller than WebKit's.) If I wanted to, I could probably embiggen it slightly and make it a lot faster, but I won't do that. Takes <16ms to parse this page...

http://i59.tinypic.com/uliti.png

>>123

still using windows 95 on Pentium?

>>117
Would you mind sharing?

>>120

You're doing the equivalent of asking a C64 democoder why she chooses to continue working on a highly constrained 32-year-old platform

Because it's fun and just a harmless e-penis contest? We're not in the need of more demos, though we do need better standards for the web. Stop wasting your time.

I appreciate your proof-of-concept browser but you're encouraging the web apping crowd to live on.

>>123
STOP USING TINYPIC
I HAVE TO ENABLE JAVASHIT JUST TO SEE YOUR FUCKING IMAGES

>>127

JS is the best that happened to programming since COBOL.

>>128
Only if you have a fetish for anal prolapses.

>>127
You are doing something wrong then, the image transmits just fine with a direct link.

>>124
Wine32 on a Nehalem.

More benchmark results... this time using a ~1MB HTML file (http://www.w3.org/TR/html5/syntax.html )

Tokeniser + Parser: 190-200ms (5.0-5.3MB/s)
Tokeniser + Parser, tags/comments only: 110ms (9MB/s)
Tokeniser + Parser, text only: 4250ms (243KB/s)
Tokeniser only: ~5.6ms (180MB/s)

Making DOM nodes and adding them to the tree is the slooooooooow part. That's the code which is currently in C.

That text-only result is interesting... when the input is 100% text with all the tags stripped out, looks like a strcat/strlen is the problem. That was dumb and stupid string handling.

Tokeniser is more than fast enough at the moment.

>>126
U MAD? Refer to >>120.

>>131
Shalom!

After fixing some stupid string handling...

Tokeniser + Parser: 168ms-170ms (5.9-6.0MB/s)
Tokeniser + Parser, text only: 24ms (41.4MB/s)

More than two orders of magnitude difference between strcatting and using stored lengths. The size increase of storing a length is tiny and the benefit is huge. The lesson here is: for performance, never use strcat(), always store lengths, and only strlen() once.

>>133
Is there any real programmer who uses strcat on real programs? There is no reason not to use strcpy (str + n, str2);

>>134
Enjoy you're buffer overflows.

>>134
Is there any real programmer who uses strcat on real programs? There is no reason not to use the lazy Text builder.

http://hackage.haskell.org/package/text-1.1.1.3/docs/Data-Text-Lazy-Builder.html

>>135
You can't have buffer overflows with something like this except if you are a homosexual salamander

>>133
I never liked null delimited strings.

>>138
What else do you suggest?

>>139
I guess he suggests something like this
struct string
{
char *str;
size_t size;
};

or the more generic
struct object
{
void *obj;
size_t size;
};

Or something like Pascal does
struct string
{
size_t size;
char str[];
};

>>139
I like the old DOS string functions that you called with interrupts, delimited with `$'.

>>141
"$-terminated strings should be good enough for anybody." — Bill Gates

The buck stops here.

This page, which has grown since the last time I benchmarked it (>>123), now takes just under 10ms.

>>134
memcpy() is superior.

>>135
If you can't do the absolutely trivial arithmetic needed for determining the right lengths ("maths is hard!") you should not be doing any programming at all.

>>140
For my use the best option is probably null-delimited with prefix-length, i.e.

char *to_nstr(char *str) {
long sl = strlen(str);
char *t = malloc(sizeof(long) + sl + 1);
if(t) {
*((long*)t) = sl;
memcpy(t+sizeof(long), str, sl + 1);
t += sizeof(long);
}
return t;
}

Read-only-compatible with existing C APIs, but contains a length that can be used by functions aware of it.

>>144

memcpy() is superior.

Only if you know the size of the second string

>>144

For my use the best option is probably null-delimited with prefix-length

Aha, so it's the same as the last option but a little more unreadable

After some more benchmarking, I've determined that just inserting nodes into the Win32 TreeView is taking up quite a significant portion of the time... with the same ~1MB file as before:

Tokeniser + Parser: 168ms-170ms (5.9-6.0MB/s)
Tokeniser + Parser, text only: 24ms (41.4MB/s)
Tokeniser + Parser - TreeView updates: 70ms (14.3MB/s)

59% of the time is spent in UI code, meaning the actual parser/DOM node creation is now over 4x faster than that of Chrome.

>>145
That's the whole point... lengths are stored so there shouldn't ever be a need to count, except when e.g. parsing things.

Further extension of the length-delimited string idea: at -4 from the pointer is the strlen, and at -8 is stored the allocated size, meaning I now get resizeable buffers (RBS) that are also downward-read-compatible with APIs expecting LDS and NTS. It's like an OOP class hierarchy, except without the bloat: RBS > LDS > NTS

>>146
Only if you're illiterate. The code actually looks far nicer in Asm than in C, because there's no type system that gets in the way; a ldstrlen() becomes a simple mov eax, [eax-4]. An rbldstrcat() looks like this:

char *rbldstrcat(char *rbs, char *lds) {
long rbsl = LDSTRLEN(rbs);
long ldsl = LDSTRLEN(lds);
rbs = rbs_append_size(rbs, ldsl);
memcpy(rbs + rbsl, lds, ldsl + 1);
LDSTRLEN(rbs) += ldsl;
return rbs;
}

Very similar to Delphi strings - too bad Delphi's compiler is terminally retarded (http://dis.4chan.org/read/prog/1318534478 )... MFC has CString which is similar, but they also put the fields in the wrong order so that LDS aren't compatible with them.

So what's the alternative?

>>148

gay sex

>>147
Shalom!

http://limpet.net/mbrubeck/2014/09/08/toy-layout-engine-5-boxes.html

What about different character encodings?

>>152

I've yet to see any reason to use characters above 7-bit ASCII.

>>152
What about them?

>>154
Does Cudder's so-called browser handle anything outside ASCII?

In particular the HTML5 spec mandates an encoding sniffing algorithm.

>>155
HTML5 is garbage.

>>156
Why do you say that?

>>152,155
Anything ASCII-compatible such as ISO8859-x/Windows-125x, UTF-8, GB18030, Big5, Shift-JIS will Just Work™, the only non-ASCII-compatible encoding supported is UTF-16 which gets internally converted into UTF-8 (at the expense of another copying operation). Hence http://progrider.org/prog/read/1409320992 .

>>158
Shalom!

>>157
HTML is utter shit. Why do you even need an explanation for this?