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

31–40 of 40 posts

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

#31

Post by chrisjj »

himata4113 wrote: post #23
chrisjj wrote: post #21

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. 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.

> Traits are harder to find

Sure, but what matters is whether that's too hard for an "AI".

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

#32

Post by tenacious_tuna »

silon42 wrote: post #18
stinos wrote: post #14

Even without this performance hit, an often used way for implementing 'auto scroll to top/bottom' is to first check if there's no other stuff coming in before starting to actually scroll. This goes unnoticed by the user but drastically reduces the number of updates (and in this case, number of calls to scrollHeight) needed when a lot of data is coming in in batches. Principle is like: receive message, add to buffer a…

IME, this absolutely doesn't go unnoticed, except in trivial cases.

Drives me nuts whenever I reach the bottom of a scroll window and I can feel the network call happening before stuff starts loading again. It's 8ms from me to the local CDN and I've got gigabit, but it feels like every dang site is slow as hell these days.

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

#34

Post by WorldMaker »

devld wrote: post #30

> 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).

To my understanding today it depends on the JS engine and more importantly what JIT stage that code is in. JITs optimize const/let in ways that they can't optimize var now.

Which is to say that if someone tells you that you should in general never use const/let for "performance" they are probably wrong, but yes there probably are still edge cases and microbenchmarks that make var look faster on some engines.

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

#35

Post by himata4113 »

chrisjj wrote: post #31
himata4113 wrote: post #23

Earlier quoted context omitted.

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.

> Traits are harder to find Sure, but what matters is whether that's too hard for an "AI".

1 read vs realizing that lsp exists and using it correctly, even if ai is smart that's more token burn and it is slower making zig 'better'.

It also has to realize that "Drop" exists and know what it does since there's nothing in code that clearly says "this object is automatically dropped by the compiler on scope end.

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

#36

Post by Groxx »

tenacious_tuna wrote: post #32
silon42 wrote: post #18

Earlier quoted context omitted.

IME, this absolutely doesn't go unnoticed, except in trivial cases.

Drives me nuts whenever I reach the bottom of a scroll window and I can feel the network call happening before stuff starts loading again. It's 8ms from me to the local CDN and I've got gigabit, but it feels like every dang site is slow as hell these days.

Preloading certainly does seem to be a lost art at times, yeah. It's just so complicated, we might never climb back to such heights.

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

#37

Post by crote »

ameliaquining wrote: post #29
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.

Why? Plenty of web APIs have been redesigned since then. Nobody is going to stop the browser makers from introducing an alternative and deprecating the old one for removal 25 years from now.

If they can remove and , they can provide an alternative to this.

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

#38

Post by stinos »

silon42 wrote: post #18
stinos wrote: post #14

Even without this performance hit, an often used way for implementing 'auto scroll to top/bottom' is to first check if there's no other stuff coming in before starting to actually scroll. This goes unnoticed by the user but drastically reduces the number of updates (and in this case, number of calls to scrollHeight) needed when a lot of data is coming in in batches. Principle is like: receive message, add to buffer a…

IME, this absolutely doesn't go unnoticed, except in trivial cases.

I was talking message logs for example; is that trivial? I.e. what do you mean exactly? Do you notice the difference between 1 line of text being added every 16.6ms vs 3 lines every 50ms? And if so is that a problem?

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

#39

Post by ameliaquining »

crote wrote: post #37
ameliaquining wrote: post #29

Earlier quoted context omitted.

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.

Why? Plenty of web APIs have been redesigned since then. Nobody is going to stop the browser makers from introducing an alternative and deprecating the old one for removal 25 years from now. If they can remove and , they can provide an alternative to this.

hasn't been removed; although it is deprecated, the HTML standard requires browsers to support it, and they all do, and I don't think anyone is planning to change this.

hadn't worked for most users since 1998; Internet Explorer never supported it, and neither did Chrome or Safari. The only browser that dropped support for it was Firefox, which merely brought it in line with how other browsers had always behaved. Furthermore, when it was removed, content in existing pages' tags still appeared on the page; it just no longer blinked. So there was probably very little breakage, at least if we define "breakage" as "behavior change that causes problems for end users" rather than "any behavior change at all".

By contrast, if they remove scrollHeight, every existing page that uses it will crash.

There's actually a footnote to the saga that illustrates this perfectly. JavaScript strings have a .blink() method that surrounds them with tags (e.g., "a".blink() returns "a"). With hindsight we can say that making this a fundamental string operation was profoundly silly to begin with, and now that doesn't even work anymore it's basically 100% useless. Yet it remains in the standard, and every browser still supports it, and they almost certainly always will. Because while removing didn't cause breakage, removing .blink() absolutely would.

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

#40

Post by tenacious_tuna »

Groxx wrote: post #36
tenacious_tuna wrote: post #32

Earlier quoted context omitted.

Drives me nuts whenever I reach the bottom of a scroll window and I can feel the network call happening before stuff starts loading again. It's 8ms from me to the local CDN and I've got gigabit, but it feels like every dang site is slow as hell these days.

Preloading certainly does seem to be a lost art at times, yeah. It's just so complicated , we might never climb back to such heights.

i feel that way about most web design principles these days. For a brief window it seemed like every website had automatic handling for dark/light mode based on system preference, or at least a toggle, but I feel like that's gone the way of the dodo. Or popups, consent banners, images loading and reflowing an entire article...

maddening.

Post reply on HN