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

Fast machines, slow machines (2023)

jmmv.dev

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Fast machines, slow machines (2023)

#51

Post by cesarb »

kreco wrote: post #22
drob518 wrote: post #12

Startup time has always been a bit of a sketchy metric as modern OSs and languages do a lot of processing on application launch. Some scan for viruses. On Macs you have checks for x86 vs Apple silicon and loading of Rosetta if required. Managed runtime environments have various JITs that get invoked. And apps are now huge webs of dependencies, so lots of dynamically linked code being loaded. A better metric is their…

Why not both? The applications are launched at startup time because they have runtime startup slowness. The applications have startup slowness because of the JIT runtime/deps/.dll. At the end of the day, end users pay for the cost of developer convenience (JIT and deps most of the time, even thought there are some case where dynamic linking is alright) because they don't do native apps. Offloading everything at start…

> Replying to your specific point about virus scans. For some (naive) reason, I expect them to run a single time against a binary app that is never changed.

Playing devil's advocate: the executable might not have changed, but the database of known virus signatures changes daily or more often. Either every single executable would have to be re-scanned every time the database updates, or the executable has to be lazily scanned on load.

Re: Fast machines, slow machines (2023)

#52

Post by Pet_Ant »

bigstrat2003 wrote: post #47

I think that the author is spot on about the cause of the problem: software developers (meaning the organizations that produce software, not necessarily the individuals writing code) prioritize selfish goals like ease of development or profits over the quality of the product. This has resulted in a lot of software being quite terrible. Not just slow (though definitely slow), but also buggy and crammed full of feature…

> software developers ... prioritize selfish goals like ease of development or profits over the quality of the product.

What is an unspoken assumption in this type of complaint is that the software would still have gotten written if it had to be more handwritten. The amount of projects I've seen beached on an outdated version of Spring because they neglected upgrading even patch releases convinces me that more effort is just not tenable.

Re: Fast machines, slow machines (2023)

#53

Post by erinaceousjones »

maccard wrote: post #9
coolcase wrote: post #3

Are mobile devices slow/unresponsive. I haven't experienced that unless I realllllly cheap out. Or after 4 years of OS updates on Apple devices for some reason. Androids seem OK in this regard.

I switched from android back to iOS last year. There seems to be some sort of inherent latency in either android or Samsung’s UI that causes the UI thread to lag behind your inputs by a noticeable amount, and for the UI thread to block app actions in many cases. Things like summoning a keyboard causing my 120hz galaxy phone to drop to sub 10fps playing the intro animation for GBoard were just rampant. All non existen…

I do wonder if part of it is down to Android default animation speeds.... Pixel 6 here, Gboard snappy enough. Something I do on every android device I own though is go into developer settings and change all the animation durations to 0.5x. Makes stuff seem snappier. In reality I'm sure it's dropping just as many frames as it async loads garbage enterprise uncompressed asset icons or whatever, but hey it shows up on screen 2x as fast!!!!

Edit: oh, no, you have a point about the UI blocking stuff, it's fine when apps are loaded and active but "cold booting" a UI component definitely has lags in stupid places, android UX feels like a web perform sometimes due to that.... Tap button, go on holiday for a week, come back and it's responded to the button press (while you were trying to do something completely different and now you've pressed something else and you're not sure what because this time the button you pressed closed the activity overlay 1ms after)

Re: Fast machines, slow machines (2023)

#54

Post by achandlerwhite »

maccard wrote: post #32
lelanthran wrote: post #13

Earlier quoted context omitted.

> incrementally async load 500 icon or text files and have them run through all the same slowness” This really shouldn't be slower when done asynchronously compared to synchronously. I would expect, actually, that it would be faster (all available cores get used).

> I would expect, actually, that it would be faster (all available cores get used). And I think this assumption is what's killing us. Async != parallel for a start, and parallel IO is not guaranteed to be fast. If you write a function: async Task LoadFile(string path) { var f = await load_file(path); return new ImageFile(f); } And someone comes along and makes it into a batch operation; async Task > LoadFiles(List pa…

well I mean you'd use await foreach and IAsyncEnumerable equivalent... async would mean the UI would not be blocked so I agree with the original commenter you replied to.

Re: Fast machines, slow machines (2023)

#55

Post by throwaheyy »

jonathanlydall wrote: post #6

I’ve recently noticed this on an especially well used app I have on my iPhone 14 with a stupid animation which regularly annoys me. Google Authenticator’s filter box, when you tap it there is a very noticeable delay after tapping the filter box and the keyboard showing. And what makes it worse is that if you switch away from the app, it auto clears the filter. This isn’t a complex app and it’s slow at doing a use cas…

This is why I do not use any google apps and deleted my google anccount. Their shitty software pisses me off.

Every time I try to use it, the UI elements shift around as I try an action as simple as activating a search box. But it is just laggy enough that you click on something a second time, since it apparently didn’t activate the first time. But by then it’s shifted everything around and you are either cancelling what you were doing, or you are taken off into some new workflow you didn’t want.

The absolute WORST is when you focus the search box and it shifts to the top of the screen. With lag, you click on the search box again, but now where it was is a list of completion suggestions and you are taken off to some search result page you never asked for.

It’s fucking infuriating and I won’t entertain it.

Re: Fast machines, slow machines (2023)

#56

Post by coolcase »

maccard wrote: post #34
genewitch wrote: post #31

Earlier quoted context omitted.

I begin to wonder if all the commenters in this thread have compromised devices. I'm on a 5 year old Samsung (the model is, I bought it new six months ago) - my Linux machines are fast (gentoo) and my windows 10 and 11 machines are fast. My kid's computer is an i3 7350k and he plays roblox, Minecraft, teardown on it with no issues. That computer is a couple years older than he is at 9-10 years old. That computer's tw…

Did you watch the videos linked in the article? > I'm on a 5 year old Samsung (the model is, I bought it new six months ago) How quick is the Share menu on your samsung? On mine, it takes about 3 seconds of repainting itself before it settles down. On iOS there's about a 100ms pause and the drawer pops up, fully populated. I found [0] which is a perfect example of this sort of bloat. > My main computer is beefy, thou…

My share is 1s. Didn't realise it was that slow. From the UI interaction I wonder if it is on purpose to avoid an accidental share.

Re: Fast machines, slow machines (2023)

#57

Post by RetroTechie »

zokier wrote: post #49
RetroTechie wrote: post #28

Earlier quoted context omitted.

It's also complexity - added more than necessary, and @ a faster pace than hardware can keep up with. Take font rendering: in early machines, fonts were small bitmaps (often 8x8 pixels, 1 bit/pixel), hardcoded in ROM. As screen resolutions grew (and varied between devices), OSes stored fonts in different sizes. Later: scalable fonts, chosen from a selection of styles / font families, rendered to sub-pixel accuracy, s…

I'm not sure your font rendering is very good example here. Windows has used vector fonts since 90s and ClearType since Windows XP. That is nearly 25 years ago. And it wasn't really much of a performance issue even back then.

Correct. Modern font rendering likely falls into that "more complex, but lightweight / useful" category.

My point was it's much more complex even though it does essentially the same thing (output character to screen).

>> There are many examples like the above

Death by a 1000 cuts! Probably much worse offenders out there that deserve being attacked.

Re: Fast machines, slow machines (2023)

#58

Post by maccard »

lelanthran wrote: post #48
maccard wrote: post #32

Earlier quoted context omitted.

> I would expect, actually, that it would be faster (all available cores get used). And I think this assumption is what's killing us. Async != parallel for a start, and parallel IO is not guaranteed to be fast. If you write a function: async Task LoadFile(string path) { var f = await load_file(path); return new ImageFile(f); } And someone comes along and makes it into a batch operation; async Task > LoadFiles(List pa…

Why would someone put an await inside a loop? Don't get me wrong... I believe you have seen it, I just can't understand the thought process that led to that. In my mind, await is used when you want to use the result, not when you store it or return it.

The same can be asked about any number of things - why would someone ever not free their memory, use a dynamic allocation, not use a lock, use an orm, not use an orm.

> I just can’t understand the thought process that led to that.

Bluntly, it’s not understanding the tools and fundamentals. Your original reply assumed that it would use all cores, for example. To me that’s obviously not true but I’m sure there’s 10 things you could list off that are obvious to you but I’d get wrong -

Re: Fast machines, slow machines (2023)

#59

Post by marcosdumay »

Borg3 wrote: post #43
marcosdumay wrote: post #35

Earlier quoted context omitted.

> But it also makes rendering each single character a lot more complex. Not millions of times more complex. Except for some outliers that mess up everything (like anything from Microsoft), almost all of the increased latency between keypress and character rendering we see on modern computers comes from optimizing for modularity and generalization instead of specialized code for handling the keyboard. Not even our har…

Im not really sure what are you talking about ;) HW become much much much faster. Mostly in speed of computing, but latency also dropped nicely. The letency bloat you see its 99% of software (OS). I still run Win2003 on modern desktop, and it flies! Really, booting/shutdown is quick. Im on spinning rust, so first start of webbrowser is slowish a bit, but once cached, its like 200ms-500ms depending on version (more mo…

Take a look on the latency of a keypress on your modern keyboard to when your CPU has the chance to first process the data, you'll be surprised. Depending on how your hardware is configured, it can reach 100ms there alone.

Your mouse has an equivalent issue, except that it's not usually optimized to the same level, so the worst case is way more common. Audio has a much worse issue, and can lag a large fraction of a second on hardware alone. And there's the network, that has optional features that are emulated by adding lags proportional to the bandwidth.

All of our hardware has become more capable with time, but that doesn't mean latency has decreased. Some kinds of latency have gone down, others have gone way up.

Re: Fast machines, slow machines (2023)

#60

Post by lelanthran »

maccard wrote: post #58
lelanthran wrote: post #48

Earlier quoted context omitted.

Why would someone put an await inside a loop? Don't get me wrong... I believe you have seen it, I just can't understand the thought process that led to that. In my mind, await is used when you want to use the result, not when you store it or return it.

The same can be asked about any number of things - why would someone ever not free their memory, use a dynamic allocation, not use a lock, use an orm, not use an orm. > I just can’t understand the thought process that led to that. Bluntly, it’s not understanding the tools and fundamentals. Your original reply assumed that it would use all cores, for example. To me that’s obviously not true but I’m sure there’s 10 thi…

> Your original reply assumed that it would use all cores, for example.

Sure. My original reply assumed that there wouldn't be an unnecessary `await` inserted inside a loop.

Unless I'm misunderstanding the code you posted, removing the `await` in the loop would use all cores.

Post reply on HN