3 ms·

I can only think of one thing. The computational overhead of this parsing insanity. With the size of modern web pages and the scale. This must amount to a very

I can only think of one thing. The computational overhead of this parsing insanity. With the size of modern web pages and the scale. This must amount to a very significant cost.

bartread 2y ago
Not really. The color attribute isn’t commonly used these days - it’s literally legacy support - and, even on pages where it is used, it’s going to be a tiny portion of the overall markup. Also worth bearing in mind that parsing markup is fast, and certainly not the reason web pages can feel slow. That’s much more to do with heavy assets, poorly constructed JavaScript, long-running web service calls, excessive DOM manipulation and re-rendering, bandwidth constraints, etc. Parsing the markup on its own isn’t going to be the root cause of a meaningful fraction of web performance issues.
lblume 2y ago
Highly unlikely. The parsers are written in efficient languages, and nobody is setting <font> color attributes in a loop. Also, this is not how it is done today, and old websites are usually a lot faster than modern ones. I would even argue that the parsing CSS's color syntax is way more expensive than this comparatively simple step-by-step algorithm.
- Sesse__ 2y ago
  > and nobody is setting <font> color attributes in a loop. You would be surprised! For instance, MotionMark, one of the main web benchmarks, keeps mutating CSS colors directly on (thousands of) elements to animate them, every frame.
Cthulhu_ 2y ago
The problem there is that there's a lot of sanity checking happening in browsers; I hope there will be a new technology where things like html, css and JS are all precompiled / pre-verified so the page is executed as-is with minimal sanity checking. There was a post yesterday about Python's random() vs randint; the former just spits out a random number, the latter does a list of sanity checks on the arguments passed, whose cost adds up in many invocations. But that's a runtime sanity check, if that can be done beforehand with e.g. a stricter type system + a "let it crash / fail" attitude at runtime, all that sanity checking overhead would be gone. I mean this script / at-runtime checking is fine during development if it means shorter iterations and whatnot, but in production it shouldn't happen.
- Sesse__ 2y ago
  Hi, I work on CSS parser performance, and error handling isn't really a big pain point; if you removed all error handling overhead, you would not be likely to notice any real performance increase in your web page loading. Most of the time, you just hit the happy path anyway, and the error checks from that is an easily-predicted branch. A precompiled format (i.e., binary) _may_ help (I don't think anyone has really considered it), but “pre-verified” means it would come down to who you trust to do that verification, so it's a hard sell.

I can only think of one thing. The computational overhead of this parsing insanity. With the size of modern web pages and the scale. This must amount to a very significant cost.

bartread 2y ago

Not really. The color attribute isn’t commonly used these days - it’s literally legacy support - and, even on pages where it is used, it’s going to be a tiny portion of the overall markup. Also worth bearing in mind that parsing markup is fast, and certainly not the reason web pages can feel slow. That’s much more to do with heavy assets, poorly constructed JavaScript, long-running web service calls, excessive DOM manipulation and re-rendering, bandwidth constraints, etc. Parsing the markup on its own isn’t going to be the root cause of a meaningful fraction of web performance issues.

lblume 2y ago

Highly unlikely. The parsers are written in efficient languages, and nobody is setting <font> color attributes in a loop. Also, this is not how it is done today, and old websites are usually a lot faster than modern ones. I would even argue that the parsing CSS's color syntax is way more expensive than this comparatively simple step-by-step algorithm.

Sesse__ 2y ago
> and nobody is setting <font> color attributes in a loop. You would be surprised! For instance, MotionMark, one of the main web benchmarks, keeps mutating CSS colors directly on (thousands of) elements to animate them, every frame.

Cthulhu_ 2y ago

The problem there is that there's a lot of sanity checking happening in browsers; I hope there will be a new technology where things like html, css and JS are all precompiled / pre-verified so the page is executed as-is with minimal sanity checking. There was a post yesterday about Python's random() vs randint; the former just spits out a random number, the latter does a list of sanity checks on the arguments passed, whose cost adds up in many invocations. But that's a runtime sanity check, if that can be done beforehand with e.g. a stricter type system + a "let it crash / fail" attitude at runtime, all that sanity checking overhead would be gone. I mean this script / at-runtime checking is fine during development if it means shorter iterations and whatnot, but in production it shouldn't happen.

Sesse__ 2y ago
Hi, I work on CSS parser performance, and error handling isn't really a big pain point; if you removed all error handling overhead, you would not be likely to notice any real performance increase in your web page loading. Most of the time, you just hit the happy path anyway, and the error checks from that is an easily-predicted branch. A precompiled format (i.e., binary) _may_ help (I don't think anyone has really considered it), but “pre-verified” means it would come down to who you trust to do that verification, so it's a hard sell.