←back to thread

Windows NT on 600MHz machine opens apps instantly. What happened?

(twitter.com)
752 points dceddia | 4 comments | 23 Jun 23 14:02 UTC | HN request time: 0.946s | source
Show context
yomlica8 ◴[23 Jun 23 14:32 UTC] No.36447314[source]▶
It blows my mind how unresponsive modern tech is, and it frustrates me constantly. What makes it even worse is how unpredictable the lags are so you can't even train yourself around it.

I was watching Halt and Catch Fire and in the first season the engineering team makes a great effort to meet something called the "Doherty Threshold" to keep the responsiveness of the machine so the user doesn't get frustrated and lose interest. I guess that is lost to time!

replies(18): >>36447344 #>>36447520 #>>36447558 #>>36447932 #>>36447949 #>>36449090 #>>36449889 #>>36450472 #>>36450591 #>>36451868 #>>36452042 #>>36453741 #>>36454246 #>>36454271 #>>36454404 #>>36454473 #>>36462340 #>>36469396 #
Gigachad ◴[23 Jun 23 20:54 UTC] No.36452042[source]▶
Because the user would rather wait a minute to load Photoshop, than have MS Paint that loads instantly.
replies(1): >>36453064 #
ObscureScience ◴[23 Jun 23 22:31 UTC] No.36453064[source]▶
Note that modern versions of MS Paint (with few improvements over the original) takes seconds to load on a quad core 3+ghz machine, loaded from an SSD.
replies(1): >>36455106 #
winrid ◴[24 Jun 23 03:10 UTC] No.36455106[source]▶
Is this just the C# runtime being slow or just lots of abstraction?
replies(1): >>36496930 #
ObscureScience ◴[27 Jun 23 18:37 UTC] No.36496930[source]▶
I would not say that the C# runtime is slow, but it is a JIT compiler that is not optimizing for start-up (as far as I know), and it is "doing a lot of work" at runtime to achieve the eventual performance it is capable of. Start-up time is not the most important property for a lot of services, but for user applications it's pretty high up there, so if the underlying runtime is not optimizing for that this shows a disconnect in the choice of technology stack.

I'm quite impressed of both .NET and OpenJDK in some metrics, but it is often not resource efficient, which is something I do value.

One example of an application that works as I would expect others to do is MuPDF, Being able to open 20MB+ PDFs in 1/10 seconds on a 10 years+ old laptop.

By the way, does anyone know why Debian launches LibreOffice so much quicker than Ubuntu, Fedora or Archlinux (or any other distro I've tested with)? In Debian its 1-2 seconds, and the others 5-10 seconds. I mean it could be included extensions or how they are configured, but I'm honestly interested.

replies(1): >>36500190 #
1. winrid ◴[27 Jun 23 23:33 UTC] No.36500190[source]▶
Maybe you're using the older Java based libreoffice on the other machines? It was mostly rewritten in C++.
replies(1): >>36504994 #
2. ObscureScience ◴[28 Jun 23 11:36 UTC] No.36504994[source]▶
That's pretty odd to assume. All but Debian are running more or less the latest, and Arch is on the "fresh" track.
replies(1): >>36507039 #
3. winrid ◴[28 Jun 23 14:31 UTC] No.36507039[source]▶
Did not assume. Asked, maybe the other distros are old versions. Not sure why else there would be a huge difference... maybe flatpack/snap dependencies not in fs page cache.
replies(1): >>36511974 #
4. ObscureScience ◴[28 Jun 23 20:16 UTC] No.36511974{3}[source]▶
Ok, sorry for assuming your intent. No, its nothing like that. They are all the distro provided stable versions installed as "regular" applications.

And it seem to be the start up process that differs, as putting them all in a ram-disk does not alleviate the issue, and restarting the app cuts the time in ~1/2 but equally for each distro.

My guess, as I said first is what default libraries as loaded, and possibly how they are configured. I do however find it strange that this has not been mentioned elsewhere as I've been struck bu this difference for years, when I happen to load a pure Debian install (not what I usually use).