55 ms·

Fast machines, slow machines

• jerf 3y ago
  There's actually an answer to this; if you compare the Windows machine to the average spec from the time it was released you'd probably find comparable performance. This is not a coincidence. What is happening is this: Work is put in to attain the minimum level of performance a paying user will find acceptable. This threshold has not changed, so in general, neither has real performance. The places where modern computers actually strut their stuff is where the paying users care a lot. For example, a game pushes 120Hz at 4K because the paying customer cares. Video editors care about every last bit of performance because at scale each bit becomes seconds to minutes to hours pretty quickly. (There's an averaging effect to. That game paying customer might like it if Windows was snappier, but in that market they're just another voice in the crowd of people who on average are satisfied with the current status quo.) "Paying customer" is important too because you can almost measure how much social power the user has by how slow the software is. Why is the point-of-sale device in the checkout miserably slow? Why does the device the desk receptionist is using at your national-scale bank need 30 seconds just to pull up your appointment information? Those people have no social power, so they get to just sit and wait while the computer swaps things in and out for a truly simple task. Executives get machines that can switch between email and the browser in a heartbeat with the other 24 gigs of RAM and 6 cores do nothing. Using what machines the developers get as a metric for how much the company cares about them is something smarter developers have been doing for a while; if your developer interviewer uses the 8 minutes it takes their machine to boot to sing the praises of the engineering culture the company has, well... make appropriate judgments. (In 2023 this almost impresses me. Setting up a computer that needs 30 seconds to switch between a calendar and an email is almost a challenge now. You need to harvest those last few precious $10/unit to give them really shitty hardware and combine it with an almost sociopathic dedication to layering on enough virus scanning and tracking software to slow down a cheap machine even so. Even the cheap stuff shouldn't be that slow!) If you work at it even a bit on Linux, you can set up a very responsive system. You've been able to for a long time, really. But you may find you don't get to use the latest and greatest of the heaviest weight desktop system at the time. It's a lot easier on Linux to use the stuff from years ago that flies now. Emacs use to be joking referred to as "Eight Megabytes And Constantly Swapping"; now it's a "light-weight" text editor. (Though it doesn't quite start instantly for me, it is under a second in my configuration. YMMV.)
  • _dain_ 3y ago
    >if you compare the Windows machine to the average spec from the time it was released you'd probably find comparable performance. This is not the case, he specifically debunks it it in the twitter thread. He took a contemporary late 90s machine with modest specs, and it was still snappier than the modern PC with Windows 10. And even if that were the case, it does not follow that we should accept modern machines not being able to load Notepad instantly. Modern machines are hundreds of times more powerful than 20 years ago, but Notepad has not become hundreds of times more featureful.
    • jerf 3y ago
      There is a lot of fuzz in that comparison. I used machines at that time. They were not snappy if you had the average specs. I am not convinced he got that in his comparison. In particular modern iterations of those old machines are usually stuffed with RAM by comparison because since then it has become so dirt cheap to do that that it's not worth not doing it. I acknowledge he at least tried but I'm not convinced he succeeded and even by his own text you can tell he's not exactly putting a huge marker down on the older system being the exact right system. Average specs typically dipped into swap. (The supposed minimum specs were often a joke.) "accept" I'm a bit at a loss as to how anything I said sounds like we should accept this. Did I not call it almost sociopathic how IT departments manage to slow machines down for people who have no social power? Does that sound like I think this is hunky dory?
      • anthk 3y ago
        Not snappy on reading I/O but the UI was fast as hell. With SSD's a Pentium IV with SSE2 support with TDE3 under Slackware Linux running Konqueror, Amarok and Kopete (Konqueror against a non-JS site) will run circles around lots of core i7 setups with Spotify and Slack...
    • marcosdumay 3y ago
      > it does not follow that we should accept Just to point that all the GP said is that we do accept. There's nothing there about what we should do.
• isaacfrond 3y ago
  This is the reason I like SumatraPDF. It has an old-fashioned user interface, a rather limited set of features, but boy it opens fast. I wish there were more apps in that mold.
  • _dain_ 3y ago
    Zathura is a fast PDF viewer for Unixes, it's simple and snappy like Sumatra.
    • amadeuspagel 3y ago
      Sioyek is fast cross platform PDF viewer.
    • bee_rider 3y ago
      In general Linux seems pretty snappy. I like evince, which is not particularly svelte (but it does color inverted rendering and reloads your PDFs when they change on the disk, so it is nice for writing at night). He mentions Linux in the blog post. But then goes off on a tangent about cross-platform programs. I think he must be primarily a windows guy or something? In general cross platform programs suck, it is well known, so everyone avoids them.
      • ericd 3y ago
        Any reccs for a snappy linux desktop environment?
        • bee_rider 3y ago
          I’m boring, I just use i3 or sway, like the rest of the hipsters. So, no recommendation I guess, since it is just a window manager.
          • ericd 3y ago
            Haha thanks, I think I'll finally give those a try, I've been trying to make KDE work, and it just doesn't.
• jacknews 3y ago
  "macOS ... the desktop switching animation is particularly intrusive, oh god how I hate that thing" Why oh why won't Apple let you turn this off? It annoys if not nauseates so many people. This is is just one example, but indicative of their mindset, why I dislike Apple, and use linux whenever I can. It's such a calming joy to switch instantly between desktops without the rushing-train effect.
  • jwr 3y ago
    The desktop switching animation is the reason why I don't use Spaces at all. I just can't force myself to "be along for the ride" every time I switch, which I might want to do very often.
    • tecleandor 3y ago
      There's one situation where it's specially terrible: screen sharing. When I'm on a Zoom call, and somebody is sharing their screen, and begins switching spaces... I get dizzy (and the streaming compression goes crazy).
  • arjunbajaj 3y ago
    Go to Settings -> Accessibility -> Display, turn on Reduce Motion. This makes the train effect go away, but there is still another very slight fade-away effect when switching desktops, albeit much less annoying.
    • dlisboa 3y ago
      Problem with that is that it's global. It can even affect websites if they use a media query for it. I'm ok/enjoy the other animations (I rarely see them, but appreciate when they happen), the only animation I wanted to disable was the desktop switch one. It was once possible I think, but it seems that's impossible on new versions of macOS. Spaces are unusable because of that as a programmer. I'd love to have a terminal in one space and browser in the other, but the delay in switching between both is very noticeable and considering how many times I'd do that it'd probably take minutes off my day.
• scottapotamas 3y ago
  I know it's easy to point at Electron specifically for examples of poor performance (and the author acknowledged it) but Spotify isn't a great example - it's the CEF flavour of web based frontend. Slack on the other hand... </nitpick>
  • lawgimenez 3y ago
    Always reminds me of the YouTube interview of Todoist's CTO where he was asked by the JetBrains guys what is the architecture of the desktop, and CTO sheepishly said Electron and the JetBrains interviewers couldn't stop laughing.
    • Tactician_mark 3y ago
      If anyone else is curious, they're talking about this video (happens at 5m42s): (https://www.youtube.com/watch?v=z-o9MqN86eE#t=5m42s https://www.youtube.com/watch?v=z-o9MqN86eE#t=5m42s)
  • nunez 3y ago
    that's why I use Slack in the browser. It's very snappy and much less power-intensive.
    • ta988 3y ago
      Does it support the video/screen sharing/huddles now?
      • manx 3y ago
        Linux: In Firefox no, in Chrome yes.
  • smcleod 3y ago
    It really is all electron apps. The best I’ve used is VSCode (by far), but it’s still a resource hog.
• DeathArrow 3y ago
  They didn't use Javascript frameworks to write desktop apps in '90s and 2000s. Also, they concentrated first on functionality and second on the looks.
  • AnIdiotOnTheNet 3y ago
    Also they didn't consider themselves to be unique and special snowflakes that needed non-standard widgets and theming. Also the internet wasn't as big a thing so marketing hadn't taken over computing yet.
    • anthk 3y ago
      >Also the internet wasn't as big a thing so marketing hadn't taken over computing yet. Java it's an exception. Every company and his granma used that.
      • adamc 3y ago
        Yes, and Java was justly reviled at the time for slow startups.
    • ryandrake 3y ago
      > Also they didn't consider themselves to be unique and special snowflakes that needed non-standard widgets and theming. Ugh, this hurts my soul. I've worked with way too many designers who simply had to use their own icons and menus and scroll bars and drop-downs and on and on. Yea, let's throw out the person-centuries of interaction design research that the OS vendor put into the standard controls so that you, 3 years out of design school, can impose your "improved" version of them.
      • shaan7 3y ago
        Apparently designers need to do that for "brand identity" and need to "differentiate ourselves"
        • 3y ago
• djhworld 3y ago
  I agree with a lot of the points in this article but I think the ship has long since sailed, it seems very unlikely to me that companies will revert to native frameworks over electron/chromium, the incentives are not there.
  • zokier 3y ago
    "Native" is not really the right thing to look in here. As the article notes, even Windows built-in apps like calculator (/notepad/explorer/paint) are still "native" to some degree (certainly not electron based) and nevertheless dog-slow compared to their predecessors.
    • anthk 3y ago
      Any Windows users should have switched to something like Qalculate. Or the calculator from ReactOS, which is virtually the same and it would run and look native under Windows.
  • AnIdiotOnTheNet 3y ago
    Ok. Can we at least revert to sanity in the FOSS realm then? My guess is no, since for many writing FOSS software is just a way to hone their saleable skills for BigCorp where they'll spend their days finding new creative ways to put ads in front of people's eyes.
  • rirze 3y ago
    There's a new wave of C++/Rust GUI libraries that are looking to be the frontier of bridging the gap from cross-platform -> native frameworks. If that bet pays off, we might have an alternative to Electron. Would be a couple of years down the road however.
• bee_rider 3y ago
  > Linux is probably the system that suffers the least from these issues as it still feels pretty snappy on modest hardware. […]. That said, this is only an illusion. As soon as you start installing any modern app that wasn’t developed exclusively for Linux… the slow app start times and generally poor performance show up. This is not an illusion. Cross-platform programs suck, so everyone avoids them, right? Electron apps and whatnot are universally mocked. You would only use one for an online services like Spotify or something. The normal use case is downloading some nice native code from your repo.
  • mschuster91 3y ago
    > Cross-platform programs suck, so everyone avoids them, right? The thing is, cross-platform tooling sucks. A plain CLI program is already bad enough to get running across platforms - even among Unix/POSIX compliant-ish platforms, which is why autoconf, cmake and a host of other tools exist... but GUI programs? That's orders of magnitude worse to get right. And games manage to blow past that as every platform has their completely own graphics stack. Electron and friends abstract all that suckiness away from developers and allow management to hire cheap fresh JS coding bootcamp graduates instead of highly capable and paid Qt/Gtk/SDL/whatever consultants.
    • hardware2win 3y ago
      >consultants Who? I see people constantly talking about those "consultants", yet what they are? Just dev that has single-person company?
      • jcelerier 3y ago
        there's a ton of consulting companies which are humonguous. Companies like Accenture with 780000 employees, Tata Consultancy with 488000 consultants, CapGemini with 300k-ish... it's one of the largest businesses in the world
        • anthk 3y ago
• gumby 3y ago
  I strongly believe this. I think there’s an important additional factor, which is how dynamic so much UI is these days. So much is looked up at runtime, rather than being determined at compile time or at least at some static time. That means you can plug a second monitor into your laptop and everything will “just work”. But there is no reason it should take a long time to start system settings (an example from the article) as the set of settings widgets doesn’t change much — for many people, never — and so can be cached either the first time you start it or precached by a background process. Likewise a number of display-specific decisions can be made, at least for the laptop’s screen or phone’s screen, and frozen. Here’s some sobering perspective on this from 40 years ago: https://www.folklore.org/StoryView.py?story=Saving_Lives.txt https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
  • marcosdumay 3y ago
    The number of monitors was also checked at runtime at the 90's. The only difference is that by then it was checked only at startup, and now there some aynchronous function that checks it all the time... What is to say that now it should be faster. On any of the complex Linux DEs, the set of settings widgets was always set at startup, since those complex DEs existed. On Windows that varies from one interface to another (there are many), but at least for Win10, things have gotten much more static on the new interface. (I dunno about 11.) Anyway, the amount of things you can read from the user on a Windows app startup time is staggering. The applications on the article have many orders of magnitude less (relevant) data to deal with.
    • ryandrake 3y ago
      The "plug in a monitor" case is an example where computers are hilariously (and likely unnecessarily) slow to do something that should be simple. Say I have two monitors plugged in and running. When I plug in a third one, here's what happens: 1. Monitor 2 goes blank. 2. Monitor one flashes off then back on. 3. Monitor 2 comes back on. 4. Both monitors go off. 5. All three monitors finally come back on. Putting on my developer hat, I kind of know what's going on here. The devices are frantically talking to the device drivers, transmitting their capabilities, the OS is frantically reading config files to understand where to display the virtual desktops, everyone is frantically handshaking with everyone else. It's a terrible design and should not be excused. Putting on my end-user hat, what the fuck is this shit? I just plugged a monitor in. I'm not asking the computer to perform wizardry.
• avidphantasm 3y ago
  There is no mention in this article on the effect of modern security measures on desktop app latency. I'm thinking about things like verifying the signatures of binaries before launch (sometimes this requires network roundtrips as on macOS). Also, if there are active security scans running in the background, this will eventually effect latency, even if you have lots of efficiency cores that can do this in the background (at some point there will be IO contention). Another quibble I have with the article is the statement that the visual effects on macOS were smoothly animated from the start. This is not so. Compositing performance on Mac OS X was pretty lousy at first and only got significantly better when Quartz Extreme was released with 10.2 (Jaguar). Even then, Windows was much more responsive than Mac OS X. You could argue that graphics performance on macOS didn't get really good until the release of Metal. Nowadays, I agree, Windows performance is not great, and macOS is quite snappy, at least on Apple Silicon. I too hope that these performance improvements aren't lost with new bloat.
  • wsinks 3y ago
    I'm glad you mentioned this in the comments - I was wondering if they were going to touch how applications are sandboxed and everything. I would imagine that is a large part of current 'sluggishness'.
    • taeric 3y ago
      Almost certainly not? Sandboxing and anything non-visual can happen at a ridiculously fast pace. I'd suspect a lot of this is offloading so much of the graphical setup to not the application. Feels like we effectively turned window management into system calls?
    • alpaca128 3y ago
      If those mythical safety features actually make an impact then shouldn't they slow down everything, including a hello world program? Yet the performance gap between well-optimized and sluggish software only grows.
      • oriolid 3y ago
• davegauer 3y ago
  "Retrofitting performance into existing applications is very difficult technically, and almost impossible to prioritize organizationally." While this may not be the only explanation for why this trend continues, I think it's *spot on* to explain why this continues in commercially-funded software.
• zokier 3y ago
  Its not just that current crop of systems are laggy, but there aren't even clear paths towards recovery. Maybe xilem will get released and mature at some point for devs to be able to rally around it and build new desktop experiences with great perf again, but the timeline for that feels more like in 2030s with great deal of uncertainty. But in general I don't see any groups or projects taking serious, principled, look into making desktop performance great.
• strathmeyer 3y ago
  Used to be you would click on a URL and the page would load immediately, now there's a half a second wait so you can be tracked before they feed you the page. It's very noticeable.
  • robbintt 3y ago
    Google tracks eveything in their ecosystem this way and it's so anti-customer.
• nunez 3y ago
  I don't know. On one hand, lag is real. I rebooted my M1 Mac mini yesterday running Ventura, and while it only took a few seconds to boot to the desktop, it took, like, two minutes for it to stop beach-balling and finish initializing. (It was most likely waiting on network I/O to finish, but still.) On the other hand, machines are faster than ever before while doing more than ever before, and apps are more flexible and change more quickly (largely in part to super approachable cross-platform frameworks like Electron). A few milliseconds of UI latency will bother almost no-one. On the other _other_ hand, Julio's demo of using Windows 2000 on an time-appropriate machine is best case. I definitely remember waiting what felt like eons for lots of useful apps to load, like Office and Internet Explorer. (Remember when browsers had startup screens?) He's definitely right about how far hardware has come since 1999. The shift to Apple Silicon was even more transformational than the transition to SSD, IMO. Julio's right in that the shift to SSD was night-and-day, but going from an Intel Mac to an Apple Silicon Mac sped up literally everything you used to an insane degree AND you got 12+ hour battery life to boot. This used to be an either-or kind of trade-off, and for Windows devices, it still is. To wit: I used an Intel Mac Pro (the trash can) last week for some audio work, and that super expensive almost-server-class machine was _slower_ than my base model M1 Mac mini at home, while running (slightly) louder and hotter!
  • TeMPOraL 3y ago
    > On the other hand, machines are faster than ever before while doing more than ever before, and apps are more flexible and change more quickly (...). A few milliseconds of UI latency will bother almost no-one. On the forking hand (distinct from your "other _other_ hand"), the "doing more than ever before" neatly cancels out "faster than ever before", which prompts a question: how useful is whatever it is our machines are doing now? Because one thing is clear: most of that extra work is not visible to the user. The increase in software capabilities is much, much smaller - nowhere near enough to explain where all the performance goes. We could break the extra work into several categories: - Support for better hardware - e.g. higher-resolution screens require more RAM (somewhat compensated by GPUs), and require higher-resolution assets to maintain (not even improve on) decent clarity, which has second-order effects on storage use (partially offset by compression) and CPU use on decompression (the price of offsetting storage use), etc. - Security features - cryptography, secure protocols, isolation, sandboxing, etc. - those all cost CPU and memory. - "Security" features - "real-time" malware scans (bane of my existence), shady anti-virus/firewall software (i.e. almost all of it), and various other parasites living off people's fear (or need for regulatory compliance), and convincing users to pay them with money, time and compute. Not (x)or, and. - Legitimate new features - handling more type and variety of content, more advanced algorithms, etc. Continuous auto-saving and collaborative editing are two big and perhaps underappreciated generic advancements. - ... ??? The first four items on the list don't seem to account for all the performance loss, especially for software that doesn't do things requiring modern security, and offers the same set of features as its equivalent 10 or 20 years ago. Often less features, even. That last point, the "dark matter" of computing, needs more detailed study. We can guess a chunk of it is developer convenience, but that's not all of it either. WRT. developer convenience - as a developer, of course I like it, but it's really getting out of hand - at this point, whatever I buy for myself by externalizing the cost on users, I still lose because I'm also the user of development tooling, and those developers externalize on their users too...
• jmmv 3y ago
  Author of the article here. Surprised to see this bubble up to the front page again (: Discussion from a few days ago based on the original Twitter thread: https://news.ycombinator.com/item?id=36446933 https://news.ycombinator.com/item?id=36446933
• cesaref 3y ago
  The prioritisation has changed. Opening apps is slower, starting new documents/views within the apps is fast. With enough RAM you just keep all the apps you are using running and switch between them. I've not started an app so far today, not sure I did yesterday either for that matter. I certainly created plenty of tabs in chrome, and new terminal windows, but those just pop as instantly as far as I can tell. Oh, and i'm on MacOS
  • retrac 3y ago
    Applications tend to stay open on Mac even with no windows open. As a KDE on Linux user, I tend to open and close apps as I use them. Very few applications take more than a second to load on a modern machine with an SSD, anyway. I find that many desktop GUI programs are slightly misbehaved for whatever reason, and consume some small but real amount of resources when idle in the background. When a dozen are open response time will be poor.
• jeffbee 3y ago
  Not that I disagree with the core point that some software gets worse over time, but I don't think it is valid to say that users have not benefitted from the ease of development afforded by Electron. Spotify has maintained its nominal price at $9.99 for 12 years, meaning its real price has fallen by one third. I don't know anything about Spotify or why they spend over a billion dollars in R&D each year, but if lack of attention to UI performance has helped cut their development costs then users might be benefitting through lower prices.
  • mrkeen 3y ago
    > I don't know anything about Spotify or why they spend over a billion dollars in R&D each year Standups, one-on-ones, team fika, NIH, retros, agile retros, incident post mortems, cross-team fika, town halls, pool/billiards, table-tennis, and testing-in-prod.
• dist-epoch 3y ago
  People keep complaining, but nobody goes back to using the old software (even on new machines). Because the old software is missing 80% of the features needed today. It's like comparing a go-kart (simple, fast, easy to use) with a car (big, slow, complex). Yet you don't see people in go-karts.
  • _dain_ 3y ago
    The old software isn't available, or it's full of security holes.
  • anthk 3y ago
    Which features? For instance, Kopete had far more features than Slack and Discord combined and using 10X less resources. With inline videos, videoconferences, inline LaTeX rendering and who knows what. Ironically Spotify and the rest of the Electron turds barely cover the 10% of what we did with Amarok and KDE3 with Kparts and using 10% of the resources. What we are seeing it's people using damn 18-wheelers with less features than a tricycle. Opera for instance was propietary but it even had a Torrent/Email client while being usable even under a Pentium 4 at amazing speeds. Now try that today with Vivaldi. More IM. Pidgin. Bloat it to the extreme with 4 or 5 or even 10 protocols being run at once while adding lots of plugins such as services for Google Translate, inline videos or HTML parsing until it uses ~512MB of RAM. Still it runs far snappier than Discord, it uses 4X less RAM and a simple Athlon/Pentium III can drive literal thousands of conversations in parallel.
  • eviks 3y ago
    Which features did the slower Notepad gained? And just as importantly - which of these features could not have been gained without a drop in startup time?
    • moffkalast 3y ago
      That makes me wonder, would a notepad executable from XP or 7 run on 10 and 11, and would it be faster? On my Win 10 machine with an SSD and animations turned off Notepad and cmd do launch almost as fast as in that NT demo so maybe it wouldn't be much of a difference.
• chickenfeed 3y ago
  I have mostly old hardware (the best computers I have is a smartphone and a macmini from 2012). I'm disappointed when I load newer Linux distros and they appear slower. Even though I now have SSDs. Browsers are really greedy. I have a machine with 2GB of ram and a single core CPU. It's a low power rig. But cannot run Windows 10, it just about did when I first installed it. Debian runs better, but a browser kills it. It's a one app only. We had someone donate us a Windows 3.1 rig once, at the time we had 600MHZ Windows 2000 machines and ME. And we were gob smacked at how fast the 3.1 machine was on some ancient hardware. Windows always used to have that fresh lightweight install vibe. But as soon as it started indexing, doing updates, and virus scanning it would drag to nothing. Along with all those system tray apps that would take an age to fire up. Partial suspend to disk made things boot faster. Like not doing the whole driver scan thing on boot. I don't know if Linux has ever taken this on board. It's a blessing and a curse as Windows doesn't like being ported to another machine, whereas my Debian disks I can swap between some desktops and laptops without much issue. There's also that weird delayed animation thing, that is meant to feel like polish. But slows down desktops. Weird animation effects and what not. I tend to run XFCE and turn off any thing like that. I'm using a Chromebook right now and this is an old machine, but still feels pretty snappy. Certainly weird and wonderful experiences between hardware. I have High Sierra on an SSD on my Mac Mini, and that's slower by far to boot than my Linux Arch box on the same age hardware. Having said that the UI always feels more responsive as it's tailored for that. Linux suffers lots for me with kcompactd or whatever it is. Some weird memory disk swap stuff. If I accidentally code an infinite loop my machine turns to complete mud, and takes about 5 minutes to recover. Whereas it boots to the browser in under 1minute. Weird huh?
  • schemescape 3y ago
    > I have a machine with 2GB of ram and a single core CPU. It's a low power rig. But cannot run Windows 10, it just about did when I first installed it. Debian runs better, but a browser kills it. It's a one app only. I put Alpine Linux on my laptop that has 1 GB of RAM and I can actually have a lot of stuff running at once, especially in the terminal (Emacs, SBCL, w3m, Deno). But yes, opening Firefox consumes all available RAM until I have to power off the machine, sadly. The lightest weight, but functional browser, I've found is Midori, but I probably wouldn't trust it for, say, accessing my bank account. It's depressing because I was initially blown away at how fast (and productive) old hardware can be... until I tried to use the web.
• ruuda 3y ago
  Related observation from 2017: https://danluu.com/input-lag/ https://danluu.com/input-lag/
• mmazing 3y ago
  A few years ago, I was working with a team that was trying to convert an entire API for a fairly straightforward application into REST api microservices. The architect wanted to break everything up into extremely small pieces, small enough pieces that many were dependent on each other for every single call. Think "a unified address service" to provide an physical address via an identifier for anything that had an address (customers, businesses, delivery locations, etc). The problem was that it turns out when you're looking up a customer or business, you always need an address, so the customer service needed to hit the address service every time. Disregarding the fact that this whole thing was a stupid design, the plan was that when you hit the customer api, the customer code would make internal http calls to the address service, etc. I pointed out that this was a ton of unnecessary network overhead, when all of this information was sitting in a single database. The whole team's argument was effectively - "it's 2015, computers and networks are fast now, we don't need to worry about efficiency, we'll just throw more hardware at it". The whole thing ended up being scrapped, because it was crippled by performance issues. I ended up rewriting the whole thing as a "macroservice" which was 60000% faster for some particularly critical backend processes. Anyway ... I think that mentality is prevalent in a lot of people involved in technology creation, technology has improved so much, moore's law etc etc etc. So let's not worry about how much memory this thing takes, or how much disk space this uses, or how much processing power this takes, or how many network calls. Don't worry about optimization, it's no big deal, look at how fast everything is now.
• bob1029 3y ago
  I strongly believe the technology becoming faster is itself the biggest problem around slow technology. The constraints of slow hardware forced developers to do things "the right way". Today, you can serialize a gigabyte of JSON before the user will likely notice. Really hard to not be tempted by this dark path of incremental performance cuts in favor of dev-time convenience. Just look a bit further down the front page of HN today and you'll find a legitimately-heated debate regarding whether ORMs bring value or no. But, who can blame the developers? The pressure from management is eternal and some of us like to spend our time on non-computer problems too. Reaching for a JSON serializer or ElectronJS over Win32 and raw SQL is an understandable decision when presented with real-life pressures. I think if we want to see good user experiences, the capitalists and management will need to start prioritizing them again (at their own expense). This is a very difficult narrative to sell, but I've had some traction in my company with "higher order consequences of good UX today means more sales in the future" kind of talk. There is also a story about pride in the product and the improvements this brings for internal operations. Imagine if your executive leadership came into the room, smack talked the electron JS pile and insisted it be rewritten from scratch while targeting native toolchains? Would that be enough of a fire to get the average developer to start thinking again or are we too far gone at this point? Clearly, we are mostly beyond the phase of "valiant developer works overtime to strive for better UX despite any and all mgmt pressures".
  • mwcampbell 3y ago
    If my cofounder told me to translate our current Electron app to something else (maybe Rust), I'd jump on it. As it is, I've wondered if I have an obligation to do so anyway, on my own time, giving up all nights and weekends until it's done. But our actual users don't even seem to care, and some have been very positive about the product.
• hammycheesy 3y ago
  > a lot of the Windows shell and apps have been slowly rewritten in C# I worked on the Shell team until late 2022. There is very little C#, if any at all. The vast majority of the Windows Shell is still C++ with a significant amount of WinRT/COM.
  • jmmv 3y ago
    Thanks for the confirmation. I’ll fix the text. What I had in mind when I wrote this sentence though is how the modern apps that people seem to like /are/ C#, such as Windows Terminal and PowerToys, and these feel quite slow to me. But, yeah, calling those the shell is a stretch.
    • IceSentry 3y ago
      Windows Terminal is 93% c++ on github. Not sure where you got the impression it was mostly c#
      • jmmv 3y ago
        Bad memory. The idea that Windows Terminal was C# was in the back of my mind for some reason but I did not verify this fact. Thanks for keeping me honest; updated the text now. PowerToys is mostly C# though, which I have also verified now.
  • torginus 3y ago
    Yeah, and as a corollary, many apps using C#/WinForms are quite snappy. Microsoft did invest a lot into having .NET apps start fast with the GAC/ngen
• sacnoradhq 3y ago
  Windows 2000 was later corrupted by XP-ification. The primary difference was 2000 was "NT 5", where the Explorer UI appeared to be split between foreground and background components. XP threw this away and went with the Windows 9x/ME shitshow as late as Vista. Windows Server 2003 (Whistler Server) was better than XP (Whistler) and was mostly an improved Windows 2000 (originally named NT 5 in the source code). I would generally consider using Windows Server 2003 for workstations instead of Windows XP because of its close compatibility with the latter. Windows XP Professional x64 (amd64) and Windows XP 64-Bit Edition [ia64] existed but didn't find many takers except in retro systems and niches where they had HP Itanium machines.
• sharikous 3y ago
  It's one of the things that are infuriating for technical folks but meh for everybody else. In the days of programs taking forever to load or web pages downloading images slowly we knew what technical limitations were there. Now we know how much sluggishness comes from cruft, downright hostility (tracking), sloppy developer work, etc.. we know this is a human problem and that angers us. But for non-technical people it hasn't changed too much. Computing wasn't super pleasant 25 years ago and it's not now. Instead of waiting half a minute for Word to load they wait 4-5 seconds for Spotify to load. They were never interested in Notepad or Cmd or Paint. It doesn't bother them that now they open slower than in 1999.
  • deleted 3y ago
    [deleted]
  • grishka 3y ago
    It's very surprising to me how much non-tech people are willing to put up with. They'd patiently wait for their phone to freeze for a solid 5 seconds because they installed an antivirus on it, and then proceed to try to use it at 2 FPS. The quality bar is so low now, it went underground. It's so easy to compete with the status quo. You just pretend that all the "progress" that happened in software development technologies over the last 15 years didn't happen. And, most importantly, you treat JS as a macro language for a glorified word processor and don't try to build actual applications with this stack.
    • daniel_reetz 3y ago
      Many non-technical users assume blame for slowness and clunkiness. So many times I've heard self-blame when helping out family. "I shouldn't have so many pictures on my desktop" (there are 8 pictures). "I just can't figure out these phones" phone is dark patterning or has hidden functionality six menu items deep and behind a swipe/long press. "I never should have let it update, it's never been the same" - a forced update.
      • sumtechguy 3y ago
        I have heard that gem for about 2 decades now. When the reality is more cpu/memory usually cleared things up. In the old times a good defrag did not hurt either. People blame themselves when a lot of the time it is rubish software/hardware. Then you have the other side of that coin. The yes clickers. If it asks a question just answer it however you need to do for whatever it is you wanted to work. Surprising number of dark patterns on that gem... Then they hand it to you and expect a miracle in 5 mins. Sorry this is the first time I have every seen something like this it may take me a few mins to figure out what is wrong before I can even begin to fix it.
• taeric 3y ago
  As noted by another thread, the Notepad example is surprisingly telling. My initial gut was to blame the modern drawing primitives. I know that a lot of the old occlusion based ideas were somewhat cumbersome on the application, but they also made a lot of sense to scope down all of the work that an app had to do? That said, seeing Notepad makes me think it is not the modern drawing primitives, but the modern application frameworks? Would be nice to see a trace of what all is happening in the first few seconds of starting these applications. My current imagination is that it is something akin to a full classpath scan of the system to find plugins that the application framework supported, but that all too many applications don't even use. That is, used to, writing an application started with a "main" and you did everything to setup the window and what you wanted to show. Nowadays, you are as likely to have your main be offloaded to some logic that your framework provided, with you providing a ton of callbacks/entrypoints for the framework to come back to.
  • deleted 3y ago
    [deleted]
• guy98238710 3y ago
  Root cause is that startup path is more crowded these days with JIT, dynamic linking, app initialization, filesystem/DB scans, sandbox initialization, subprocesses, etc. It's a natural consequence of the apps (or underlying frameworks) growing in size and complexity. Optimizing it all by hand is unreasonably expensive if not impossible. What we need instead is a way to persist the process or even whole sandbox to disk and then fork off new instances from that. That's much less work and much more effective than piecemeal optimizations (AOT, native code, etc.). Unfortunately, existing platforms and frameworks do not support forking, let alone forking from persisted app image.
  • taeric 3y ago
    This sounds hilariously like how you make a lisp executable binary. Looking back at an old discussion on emacs trying to abandon the "unexec" idea, it is notable that they saw a substantial speed benefit from the old method. (https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/)
• avsteele 3y ago
  This is everywhere. Quickbooks Online just changed significant portions of their UI such that there are noticeable delays when typing in many input fields. Its hideous and a big slowdown when trying to get work done. I don't think many of these programs are used by the people who write them.
• jmount 3y ago
  I somewhat blame the internet. Before the internet it was unheard of to wait for an application or dialogue to load. The internet normalized this deviance, and here we are.
• guy98238710 3y ago
  Perhaps what's needed is hibernation for apps? Just let all apps run forever and swap them out to disk when not in use. Hibernate the whole system instead of shutting it down while at it.
• louismerlin 3y ago
  These kinds of realizations have made me look into permacomputing [1], suckless [2] and related fields of research and development in the past few months. We should be getting so much more from our hardware! Let's not settle for software that makes us feel bad. [1] http://www.permacomputing.net/ http://www.permacomputing.net/ [2] https://suckless.org/ https://suckless.org/
  • systems_glitch 3y ago
    Yeah, totally possible to get excellent results with older hardware, and really stellar results with very new hardware, if you're running stuff that's not essentially made to be slow. I basically only upgrade workstations due to web browsers needs, and occasionally because a really big KiCAD project brings a system to a crawl. At this point even automated test suite runtimes are more improved by fixing things that stop test parallelization from working efficiently vs. bigger hardware.
    • samstave 3y ago
      I am constantly dumbfounded with the fact that the majority consumer of memory on my machine is a FN web browser! (that said, I *do* have basically like 30 tabs open at any given time... (It would be cool if dormant tabs can just hold the URL, and kill all memory requirements when dormant after N period of time..) But heck, even when I am running a high-end game on my machine, the memory consumption is less than when I have a bunch of tabs open displaying mostly text ...
      • drivers99 3y ago
        Small tangent: I wonder what people are seeing when they say they have "too many" tabs open. I had over 1000 tabs open in Firefox (macOS) and never noticed any problems. (Trying to clear them out. Down to 920 now.) 2.26 GB out of 32.00 GB is used by Firefox. I have about 70 open in Chrome (since only a certain number fit on the screen) and it's split across 12 processes which are between 12 MB and 158 MB each. I have nearly 500 tabs open (because that's the limit) on my iPhone and iPad each, in Safari.
• guy98238710 3y ago
  The more I keep thinking about this the less I am inclined to do any optimizations. This is operating system problem. OSes are supposed to implement proper sleep modes for apps instead of mindlessly restarting them. Don't throw this on devs. Attempting to fix the problem on dev side would cost billions of dollars worldwide and it would probably fail. Meanwhile, proper app sleep modes across all OSes is a comparatively small million-dollar project. Personally, I am not going to invest a single second of my time into optimizations of app launch if I can avoid it. If you are bothered by app launch performance, go hack app sleep states into Linux or other free OS instead of shouting at devs.
• beders 3y ago
  in all of this there's one constant: Mac's Finder remains a slow piece of unorganized garbage that barely works.
• remus 3y ago
  It'd be a pretty big task, but it would be very cool to see a comparison of where the both computers are spending their time. Clearly the modern machine is slower while still being significantly more powerful so it's doing a lot more stuff, but how valuable is that stuff?
  • jmmv 3y ago
    It'd be cool indeed, but it's a humongous task :) One of the reasons I showed the Surface Go 2 tablet is because it is running the Microsoft out-of-the-box experience. So... I'd expect 1. for it to behave nicely and 2. for Microsoft to have profiled and optimized this. It is true that Windows 10 (the version that originally shipped with it) behaved better, but not by much. In any case, the Surface Go 3 is a contemporary computer with Windows 11 and people quote it as only being 15% faster than the Go 2, so it's not going to be substantially better than what I showed. Apple has traditionally fared better in this regard. In general, any new computer model they launch runs the contemporary OS version perfectly well, even if the newer OS does more stuff. I also question whether all of the "extra stuff we do today" is valuable though... but the answer will depend on who you ask.
• its_the_future 3y ago
  "it's my daily driver." I think you somehow don't have any idea what a "driver" means in a computer hardware context like this.
• Animats 3y ago
  Even open source is getting worse. GIMP will stall for 10-15 seconds at startup looking for XSANE plugins. Apparently it's calling some external server, bad in itself, and that external server is slow. Worse, this delay stalls out the entire GUI for both GIMP and other programs. There's no excuse for this "phoning home". Especially for XSANE, which is a rather bad scanner interface.
  • adamnew123456 3y ago
    > GIMP will stall for 10-15 seconds at startup looking for XSANE plugins. Apparently it's calling some external server, bad in itself, and that external server is slow. Worse, this delay stalls out the entire GUI for both GIMP and other programs. Do you remember where you came across that explanation? I'd be very surprised if it weren't something like an mDNS query with a high timeout. Which is it's own problem (ideally it'd be async), but a far cry from it trying to access something on the internet.
• pradn 3y ago
  It's clear that the biggest problem is companies prioritizing their cost, at the expense of user experience. But after that, the biggest problem is clearly the framework/language you use. The maxim "premature optimization is the root of all evil" has done damage here. The problem with frameworks/languages is that by the time you finish your features and profile your code, you're already doomed. There's no way to speed up the entire framework/language, because it's part of everything you do - death by a thousand cuts. Nothing you do can improve upon the fundamental fact of running in an interpreter, with a garbage collector, with complex layout calculations (a la HTML/CSS instead of Win32), or with major choices like processes over threads, sync IO over async IO.
  • ruuda 3y ago
    Actually I suspect unnecessary use of async IO is what makes many Rust applications slow. It surely makes things slower to compile (+100s of crates dependencies for the Tokio ecosystem), it makes the binaries bigger, which in turn makes the application slower to cold start and download.
  • Nimitz14 3y ago
    Isn't all this stuff written in C++? I suspect the slowness is bad system design.
  • syntheweave 3y ago
    Well, there is a step beyond framework hell that can work, which is "living inside your own black box"[0]. This strategy intentionally supersedes the lower-level abstraction layers with a higher-level, application-focused one that eases rewriting the underlying stack "sometime down the road". It's nearly the only way you can get that. But it does require a good understanding of what the application is and does, and a lot of software isn't that: it's just more stuff that has a behavior when you click around and press keys. [0] https://prog21.dadgum.com/66.html https://prog21.dadgum.com/66.html
• retrocryptid 3y ago
  Modern operating systems are designed for three things: 1. Serve ads. 2. Consume content. 3. Compress audio and video input and upload it to someone's servers. None of these requires a responsive UI. Ticket closed, works as designed.
  • GuB-42 3y ago
    It absolutely requires a responsive UI, there are many studies that show that milliseconds of latency matter when it comes to engagement, and it is one of the most important criteria that Google uses for ranking. Of course Google is all about serving ads and content consumption. TikTok success can be largely attributed to the uninterrupted flow of content it provides. Same thing for audio and video compression, streaming is also about milliseconds, slowness breaks the experience on a subconscious level, and who knows the user may even take his eyes off the screen and get out or read a book, terrible!
    • pclmulqdq 3y ago
      OP was clearly being sarcastic, but I'm not convinced that this isn't how Microsoft et al actually see things. Latency is hard and not core to how they see the world, so might as well not invest in it. In reality, it's very important, but we're fine as long as we can ignore reality.
• qsantos 3y ago
  > For example: you might not want to use Rust because its steep learning curve means you’ll spend more time learning than delivering Related to that, it might not actually be the case: https://news.ycombinator.com/item?id=36495667 https://news.ycombinator.com/item?id=36495667. Key takeaway: > Rumor 1: Rust takes more than 6 months to learn – Debunked ! > All survey participants are professional software developers (or a related field), employed at Google. While some of them had prior Rust experience (about 13%), most of them are coming from C/C++, Python, Java, Go, or Dart. > Based on our studies, more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust. Further, a third of respondents become as productive using Rust as other languages in two months or less. Within four months, that number increased to over 50%. Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. > Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. This is supported by the students who take the Comprehensive Rust class: the questions asked on the second and third day show that experienced software developers can become comfortable with Rust in a very short time.
  • Teckla 3y ago
    > All survey participants are professional software developers (or a related field), employed at Google. This is not even remotely a good representational sample of software engineers.
    • dan-robertson 3y ago
      It seems kinda useful to me. Like, the normal problem looks much less like ‘we took competent professionals over a long time’ and much more like ‘we took 10 undergraduates over a month or two’. If you add up employed engineers at google-like companies (by which I mean large tech companies), you’ll quickly come to hundreds of thousands, and there are plenty of other companies who hire similar people. I think Google employees are reasonably uniformly distributed across that population (that is it isn’t like the Google has the best X% of them) and I think a study of such people is more interesting to me than a study of undergraduates (or indeed a study of programming language enthusiasts). I think an unrepresentative thing about Google is that they may use C++ more than many newer tech companies, and this might help for learning that.
• gavinhoward 3y ago
  I am right there with the author, all the way. I run a machine with lots of RAM and a hefty CPU and a monster GPU and an SSD for my Linux install and...a pair of HDD's with ZFS managing them as a mirror. Wat. [1] I also have Windows on a separate drive...that is also an HDD. Double wat. My Linux is snappy, but I also run the most minimal of things: I run the Awesome Window Manager with no animations. I run OpenRC with minimal services. I run most of my stuff in the terminal, and I'm getting upset at how slow Neovim is getting. But my own stuff, I run off of ZFS on hard drives, and I'll do it in VM's with constrained resources. Why? While my own desktop has been optimized, I want my software to be snappy everywhere, even on lesser machines, even on phones. Even on Windows with an HDD. This is my promise: my software will be far faster than what companies produce. Because speed will be my killer feature. [2] [1]: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat [2]: https://bdickason.com/posts/speed-is-the-killer-feature/ https://bdickason.com/posts/speed-is-the-killer-feature/
  • TacticalCoder 3y ago
    > My Linux is snappy, but I also run the most minimal of things: I run the Awesome Window Manager with no animations. Same: a very lean Linux install with the Awesome WM, now running on a 7700X (NVMe PCIe 4.0 x4 SSD in my case). I also use one of the keyboard that comes stock with the lowest latency (and I bumped its polling rate because why not). This feels not just a bit but very snappy.
  • Karrot_Kream 3y ago
    Fast software that nobody uses helps nobody. Slow software that everyone uses is, well, slow. So I'm curious: how many people use your software? I get that this topic is like nerd rage catnip but if people actually want to help users, then they need to meet users where they're at. And if "marketing" is what's needed, then maybe it is. Software is generally built for humans after all. Don't get me wrong, All of my servers at home run Void Linux and use runit. Pretty much anything that runs on them is snappy and they run on 10 year old hardware but still sing because I use software written in Go or native languages. But remembering the particulars about runit services and symlinks is something I forget every 3 months between deploying new services. Trying to troubleshoot the logger is also a fun one where I remember then forget a few months later. Using systemd, this all just comes for free. Maybe I should write all of this down but I'm doing this for fun aren't I? The reason users don't care that much about slow software is because they use software primarily to get things done.
• beardog 3y ago
  Another piece of the puzzle: file formats, database formats, and filesystems are not always optimized for SSD use (random access).
• hinkley 3y ago
  I haven't paid any attention to the robotics world in ages and in the last six months I've discovered a bunch of interesting things people have been doing with less instead of more. Particular standouts are tiny maze-running robots, and classifications of fighting robots by weight. There's a guy with a bot named 'cheesecake' that has some interesting videos. I think we could all do with celebrating the small. ESP32 and STM32 have hit a point where you can do modest computing tasks on them without having to become an embedded hardware expert to do so. I'm at one of those crossroads in my career and I'm trying to decide if I double down on a new web friendly programming language (maybe Elixir) or jump into embedded. I've done a reasonable amount of programming in the small, several times tricked into it, and while it's as challenging if not moreso in the middle of doing the work, the nostalgia factor after the fact is much higher than most of the other things I've done.
  • fellowniusmonk 3y ago
    I hadn't heard of this bot before and honestly this video is fantastic. Battlebots writ small is just as if not more compelling than the original I think. https://youtu.be/IFbMgoOWIMc https://youtu.be/IFbMgoOWIMc
    • anderspitman 3y ago
      Ok this is awesome
• cperciva 3y ago
  Not all code is slow. I can now boot a FreeBSD kernel in under 20 ms, which I'm pretty sure beats a 20 year old FreeBSD (not to mention a 20 year old Windows).
  • schemescape 3y ago
    Is this on real hardware? And does “boot” mean to a login prompt? I ask because I’ve never had a computer (no matter how fast) boot in less than 10 seconds on Windows or Linux. Just getting to the boot loader takes a good 3 seconds or more. If I have to FreeBSD to get a fast boot, I’ll do it! (On an old laptop, at least).
    • cperciva 3y ago
      That's in Firecracker, time it takes to boot the kernel aka before we start running init. Including userland -- i.e. "boot to login prompt" -- it's around 450 ms on the same VM; I haven't optimized the userland bits all that much yet. Real hardware will take longer and will vary of course; we can't do anything about the time between poweron and when the boot loader starts running, for example.
• dahwolf 3y ago
  Fully agree with the premise. Most youngish users have never even experienced true performance. Our software stacks are shit and rotten to the core, it's an embarrassment. We'll have the smartest people in the world enabling chip design approaching the atomic level, and then there's us software "engineers" pissing it away with an inefficiency factor of 10 million %. We are very, very bad at what we do, yet somehow get richly rewarded for it. We've even invented a new performance problem: intermittent performance. Performance isn't just poor, it's also extremely variable due to distributed computing, lamba, whichever. So users can't even learn the performance pattern. Where chip designers move heaven and earth the move compute and data as closely together as is physically possible, leave it to us geniuses to tear them apart as far as we can. Also, leave it to us to completely ignore parallel computing so that your 16 cores are doing fuck all. You may now comment on why our practices are fully justified.
  • Xeoncross 3y ago
    People give push back when I tell them they should drop PHP for Go or Python for Rust. It doesn't matter that it would be better for everyone and the planet. It's a prisoners dilemma. I only get rewarded and promoted for shipping stuff and meeting deadlines even if the products are slow. Thank God for open source. Programmers produce amazing libraries, frameworks, languages and systems when business demands and salary is out of the picture.
    • jeremyjh 3y ago
      Meanwhile some people have been using C# and Java for decades which perform better than Go on many benchmarks and their software is still slow as shit.
      • brucethemoose2 3y ago
        Java and C# tend to be used for big, hairy, old projects. Thats far less common with Go.
      • BigJ1211 3y ago
        I was a little skeptical of this claim, so I looked it up. C# winning happens in a handful of cases, but it's extremely rare. Go practically always wins on memory usage, even if it doesn't win the cpu benchmark. See: https://programming-language-benchmarks.vercel.app/go-vs-csharp https://programming-language-benchmarks.vercel.app/go-vs-csh... I tried finding more, but most benchmarks I could find were of poor quality.
• majormajor 3y ago
  > Nobody prioritizes performance anymore unless for the critical cases where it matters (video games, transcoding video, and the like). What people (companies) prioritize is developer time. For example: you might not want to use Rust because its steep learning curve means you’ll spend more time learning than delivering, or its higher compiler times mean that you’ll spend more time waiting for the compiler than shipping debugging production. Or another example: you might not want to develop native apps because that means “duplicate work”, so you reach out for a cross-platform web framework. That is, Electron. Small but important disagreement IME: what companies prioritize is time to market which is often the same as developer time but importantly different in one key way: it means it's no longer an issue of "lazy developers" but it's a market question of "what will users tolerate." I don't say that just to shift blame, but because it's really key to understanding what's going on - as the article notes, performance "where it matters" has gotten better and better over time. We also have a few other improvements in the last two decades that have made things like "app startup time" less important for the market: OSes that don't need to be restarted every day, and enough RAM (and good enough memory management) to manage running a ton of open apps/windows/tabs without manually quitting and re-opening apps all the time. Would you pay more for a Notepad that opened in 0.1s instead of 2.0s or whatever? Would you give up other features? Certainly a lot of people on HN likely would - and many probably already are running Linux (hell, I am on one of my machines as a daily driver) which hasn't had the same "ship features fast!!" pressures. Maybe one year Apple will do another Snow Leopard, or MS will do something similar - https://www.macworld.com/article/191006/snowleopard-3.html https://www.macworld.com/article/191006/snowleopard-3.html - but right now most folks I know are enjoying the features, even the ones that we power users often find superfluous or downright annoying.
• jiggawatts 3y ago
  When they refreshed the Calculator app in the same way as Notepad, I went on a bit of a rant and "took it apart" with tracing tools to see where the computer power was going. The problem is that modern package management tends to "drag in" unnecessary dependencies, each of which has to be loaded, remapped, virus-scanned, CRC-checked, etc... The new Calculator was loading NVIDIA libraries, Windows Hello 4 Business Password Recovery helpers, and a decent chunk of a web browser. Why? 1. Calculator gained some basic graphing capabilities, so it calls some DirectX functions, which call NVIDIA functions, which... drag in hundreds of megabytes of game driver garbage, including Event Tracing for Windows (ETW) circular logs that NVIDIA uses to spy on you. Err.. I mean "improve software quality". 2. It uses web requests (e.g.: currency conversions), which might need to go through a corporate proxy, which might need authentication, which might need Windows H4B, which might need a self-service password reset. 3. The aforementioned web requests use HTTPS and HTTP/3, which then drags in QUIC, a bunch of cryptographic libraries, CRL checking, Enterprise PKI policy, etc... The hiccup is that all of this "work" is being done by the Calculator app itself, not the operating system. The OS just provides the DLL files, it doesn't pre-cache them in any meaningful way any more. These are all user-mode libraries, so each application has to load and process them in full. Even in web development, you get the same effect. A small web site in ASP.NET / C# might have been 500 KB in the past and would load in milliseconds and then take 50 MB of memory. Now? If you add the new "session state" plugin, it drags in Azure SQL support, which needs Azure Active Directory Authentication, which needs OAuth, which needs JWT, which needs a JSON parser, which needs the new UTF8 decoders, which needs the new Memory/Span code, etc... That 500 KB app instantly bloats to 350 MB and takes 10 seconds to restart! In NT4 and 2000 authentication and web proxies were "ambient" services provided by the OS, and much of it was in the kernel or pre-loaded and shared by all applications. Summary: The transitive dependencies of user-mode libraries are always processed in full. There's no compile-time "trimming" at this level. There's no try dynamic loading any more either, "dynamic" libraries are loaded statically because of hash-verification and anti-malware checks. There's no sharing any more to avoid DLL hell. All of the above also breaks the older optimisations where code was paged in dynamically. The result is that it is "so easy" to write code now, but impossible to make it launch fast.
• nathants 3y ago
  many pc games are targeting 4ms per frame. performance matters in some places.
• brokenmachine 3y ago
  We need a way of benchmarking all the things super easily, so you can say, "version x of this app is 3.2 times slower than version y, and compared to xx software, it's 30% slower". Then the bean counters will have numbers to put in their powerpoint slides, and it can be a point of differentiation between companies. Like a standard GUI test suite. One click and it's measured. It could ignore or use predefined times for each network query.
• berniedurfee 3y ago
  There was a period where getting a new computer or phone meant you’d viscerally feel the power in your hands and everything would be tangibly snappier. Then the SW and Product teams would catch up, add more crap and it’d be time for a new machine. It seems like that cycle has ended and HW will never catch up again at this point.
• gilbetron 3y ago
  I've posted about this before, but this is a fantasy land of the "before times". Sure, a bare app on a bare system would open snappy, but who cares? Get any significant load on that machine and it begins to wither and die. It regularly took minutes to load large docs, large 3d files, large dev environments. Sure it could load a simple text file instantly, but try to do a search through a few 10,000s of lines of code and watch things slow. Modern software does have bloat, and I think we need to fix it, but modern applications are doing far more than just slamming in a text file. In 2000, OSs and apps weren't connected to anything. Their functionality was miniscule compared to what we have today, and they crashed all the time. Losing your work was a constant, which is why people learned to make constant backups. I loved win2000, but I'd never go back there (although I would like advertisement to stay the hell out of my OS!)
• 2143 3y ago
  Many years ago I daily drove Vista for about a year. Literally anything else from before or since is a vast improvement. (I've been on *nix land for a decade now — I wish my Mac (intel) was a bit more snappier, but I'm happy nevertheless).