Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Are you telling me a readonly property is wrecking my performance?

shub.club

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Are you telling me a readonly property is wrecking my performance?

#21

Post by chrisjj »

himata4113 wrote: post #15
lelanthran wrote: post #13

Earlier quoted context omitted.

> Ironically, the 'no hidden control flow' was one of the arguments against Zig in the recent Bun rewrite to Rust. Yeah, but that makes sense: if you want "hidden everything", which they appear to want due to now having a code base that has never been read by a human, then a subset of "want everything hidden" is "want control flow hidden".

Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits. The rewrite to rust from bun is as much of as PR stunt as fustration with DX of zig. Every time I want to interact with zig code I just have the AI do it since I honestly can't be asked to change 3 lines and around 3 to 5 chara…

> Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits.

You say that as if having to find traits was a problem ... for a bot.

Re: Are you telling me a readonly property is wrecking my performance?

#22

Post by giancarlostoro »

imtringued wrote: post #8
blixt wrote: post #5

The biggest performance bomb you can have in your code is a loop that does something like for (...) { el.style.height = `${something}px`; whatever.value = el.style.offsetHeight; } This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned abou…

This is true, but a much more common reason is that you have a self growing textarea and Firefox didn't support field-sizing: content until recently, so you had to let JS resize the textarea on every keypress.

I miss Firefox Quantum that effort should have continued, stuff like this makes for great candidates for that initiative to resolve.

Re: Are you telling me a readonly property is wrecking my performance?

#23

Post by himata4113 »

chrisjj wrote: post #21
himata4113 wrote: post #15

Earlier quoted context omitted.

Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits. The rewrite to rust from bun is as much of as PR stunt as fustration with DX of zig. Every time I want to interact with zig code I just have the AI do it since I honestly can't be asked to change 3 lines and around 3 to 5 chara…

> Honestly I am pretty sure AI would be better at zig than rust since zig has no hidden control flow which means that AI has the full context of any given function without having to find traits. You say that as if having to find traits was a problem ... for a bot.

Traits are harder to find since multiple traits can apply, but the one strictest one wins. They also have to be followed from generic types which adds a whole other layer of complexity, without an LSP it's a lost cause.

Re: Are you telling me a readonly property is wrecking my performance?

#26

Post by mananaysiempre »

blixt wrote: post #5

The biggest performance bomb you can have in your code is a loop that does something like for (...) { el.style.height = `${something}px`; whatever.value = el.style.offsetHeight; } This forces the browser to recalculate layout multiple times in a single frame. Separating layout changing code from measurement code will help a lot here (most frameworks out there have solved this so we don't have to be too concerned abou…

Or as Andreas Kling (jokingly) put it[1]: “STOP INTERLEAVING STYLE CHANGES AND LAYOUT METRIC QUERIES ASSHOLE”.

[1] https://nitter.net/awesomekling/status/2021932080742142056

Re: Are you telling me a readonly property is wrecking my performance?

#27

Post by embedding-shape »

francisofascii wrote: post #25

If scrollheight is not a performant property, than it shouldn't be a property. It should have been a method called calculateScrollHeight() or something to indicate that it is not cheap.

Agree, but also easy to say after it been in use for 20 years or what it is. Doing this change today would be a monumental migration, unless you provide fallbacks, and then what's the point?

Re: Are you telling me a readonly property is wrecking my performance?

#28

Post by dwoldrich »

francisofascii wrote: post #25

If scrollheight is not a performant property, than it shouldn't be a property. It should have been a method called calculateScrollHeight() or something to indicate that it is not cheap.

Element.scrollHeight first appeared in the DOM API with IE6 in 2001 as far as I can tell. That browser was the first really modern one, with javascript and CSS that could drive a dynamic layout and they innovated with things like AJAX and vector graphics. The web browser had matured from a document model with live elements to a programmable operating environment.

The API implementation was klunky though, where DOM Elements attached to the DOM became 'live' objects. Reading some of the properties would necessarily require reflowing the page in order to calculate the value. It's interesting to think about all the ways the DOM thread can stall for synchronous API's. The Paul Irish gist is always the top hit when I search:

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

The mouse event ones always get me.

I'm always impressed by how old sins like element.scrollHeight can get papered over with newer API's. You can use ResizeObserver or requestAnimationFrame() to time your reads of the property and hopefully get the reflows for cheap or free.

Re: Are you telling me a readonly property is wrecking my performance?

#29

Post by ameliaquining »

francisofascii wrote: post #25

If scrollheight is not a performant property, than it shouldn't be a property. It should have been a method called calculateScrollHeight() or something to indicate that it is not cheap.

This API dates back to 1999 if not earlier.* Lots of APIs back then weren't designed very carefully, and now we're stuck with them.

* According to https://github.com/mdn/browser-compat-data/blob/v8.0.6/api/E..., Internet Explorer 5 had it. Unfortunately, I don't know of any way to look up which Netscape versions did.

Re: Are you telling me a readonly property is wrecking my performance?

#30

Post by devld »

> I just assumed that readonly properties will always be pretty performant in general.

This is also the case for variables. var is faster than const, because for const (and let) the engine must do additional work (related to enforcing block-level scope, if I am not mistaken).

Post reply on HN