Give Mac software a few years to "catch up" and everything will feel just as slow as usual (and I'm not even joking, so far, software was always excellent at undoing any advancements in hardware very quickly).
But, I do agree that there is a lot of jank in software that we write these days. Over the weekend I started writing an application that uses glfx + dear imgui, running on a 360Hz monitor. The lack of latency was incredible. I think it's something that people don't even know is possible, so they don't even attempt to get it. But once you know, everything else feels kind of shitty. This comment box in a web browser just feels ... off.
(Except for lsp/company which occasionally just messes up everything).
Agree, and I would add that devs on some platforms have not been as thorough about using (or abusing?) all that new power. I've been able to continue use a Sandy Bridge laptop from 2011 - it'll turn 10 years old in a couple of months - because most apps on Linux still have so little complexity that you could run them on a computer from 2006. Electron-based stuff is not the norm. Adding an SSD a few years ago has been my only significant hardware upgrade.
Meanwhile, Macbook Pros that came out two years after my laptop was built can't even be updated to the latest version of macOS, before you even get to the issue of software jank.
trading speed of development with 'hardware optimization'.
Mac being a small market, some users are still opiniated/loud enough to reward nicer/native UI vs cross-ish platform lowest common denominator UI. Maybe there is hope Arm mac stays fast.
Most javascript developers are already using babel-et-al pipelines to build electron apps, which are already transpiling between major variants of javascript, and I wouldn't at all surprised to see a thing where it gets compiled into WebAssembly rather than interpreting javascript. I also think there's a thing, right now, where it's possible to build electron apps with Rust+WebASM; I'm not sure, but I think the main thrust here is it definitely would eliminate a huge chunk of the slowdown.
I guess the main takeaway is just that the development revolution that's happened recently is mainly about how insanely good browser dev tools have become, and not about javascript - javascript was just along for the ride. As an aside - I recently saw a video of someone demoing one of the old Symbolics LISP workstations, and I was shocked to realize how much they had in common with a modern browser console - specifically of being able to inspect all of your gui components, live, and look at all the properties set on them. It's provided a hell of a way for me to explain what the deal was with all the old gurus in the 80s "AI Winter" diaspora who were pretty butthurt about having to move from programming in that environment, to having to write C on DOS (or whatever else paid the bills at the time).
tl;dr it has really sick floating point double performance which directly translates to JS performance
all other numbers are floats
I'll just quote Jeff Johnson, who's looked into this and written about it - his comment[1] on this is post is quite useful:
https://eclecticlight.co/2020/11/25/macos-has-checked-app-si...
>The request to http://crl.apple.com/root.crl is simply checking the revocation status of Apple’s own Developer ID Certification Authority intermediate signing certificate. If you examine the cert in the System Roots keychain, you can see that URL under CRL Distribution Points. This request contains no information specific to third-party developers or apps. In contrast, there’s no CRL for third-party Developer ID leaf certs signed by Apple’s intermediate cert. Their status is only available via OCSP.
Notably, this:
>This request contains no information specific to third-party developers or apps.
https://eclecticlight.co/2020/11/25/macos-has-checked-app-si...
The parent comment is incorrectly stating that each request to Apple is checking a binary, and it's not. This has been well documented both here on HN and across the web.
We have taken careful care in order to write fast and memory friendly javascript if possible, avoiding using slow features of the language (the list is long, but things like forEach loops, ineffecient data structures etc) and taking care to profile and optimize.
Result is an application that feels almost as fast as native and doesn't really consume so much memory even, although we are doing canvas based graphics realtime.
My suspection is that many web-developers (and thus, qualified to developer for Electron) just don't have the tenacity or background to write efficient code.
You can write slow-ass molasses javascript code very easily. Just take somebody who has done webdev for maybe like 2 - 3 years and doesn't have any other deeper CS background. Watch what kind of memory inefficient and slow code structures, especially with javascript where you don't really understand how heavy an operation like map() can be in worse cases, or where you are creating copies of your data multiple times for example, and voila, you have a slow-ass memory-hogging electron application.
Maybe I should do a blog post about how our Electron -application is performing just to show people that you can write fast code using javascript also. But it takes skill and time, and maybe in this current day what matters is just cranking out builds that work somehow.
We have been developing this application since 2011 already, and I also develop in C++ and 3D graphics, so performance has been something I've had to think.
But yeah, there are many guides on what to avoid in JS already, how to optimize for speed and memory. But it is not definitely an easy thing to realize, as it's not inherently visible what can be slow and what not. Most blog posts at this time talk about how to optimize for the V8, and I'm not really interested in that so much, as it can be taunting to try to understand how V8 works for example.
You can make an Electron app not slow/a battery hog, but it requires working backwards from a state of "what on earth is going on under the hood here". This is the inverse of building a native application, where that complexity is often introduced by you. I personally find this significant - you can teach someone how to avoid the latter, but it can require crazy amounts of insight to learn to debug the former.
It is 100% possible to build better Electron apps. I trust almost nobody to actually commit to doing it.
Also, particular yet tangential to this thread: apps like Signal or Discord which still make their Electron apps run under Rosetta 2 on an M1 are a nuisance. I just run Discord in a browser tab at this point.
Yeah many people do not just have the time to look into this, and most companies don't really care, as we have so much RAM and CPU power these days, so I can see why for example many messaging apps just choose to write their app in Electron, instead of trying to figure out how to do it natively cross-platform, which can be a more PITA especially when you also have web as a platform.
This feels like... a trap.
I think there's a complexity in doing that which could be summarized as follows: it's possible, but the more complex your codebase, the more difficult it is to reason about how to get to or maintain that 80%.
Even if we assume that 80% is the maximum, if most products (or the notable ones that we all complain about, I suppose) are hitting 50%, then... well, that's a problem.
For full disclosure: I've defended Electron on the merits of "there is sadly no better way to ship cross-platform UI-based software". I criticize it with this in mind.
One of my former employers had the great idea of hiring hundreds of "senior" JS devs and redoing the entire frontend of the website. When it launched to production the whole system scaled at approximately 1 enterprise-grade server to 1 concurrent user.
While I applaud your efforts to teach people how to write code faster, the majority of JS devs I have found just want to hit feature-complete and go home.
And when nearly every Stack Overflow post asking about performance implications is answered with a litany of “YAGNI” and “premature optimization”, its not hard to see why.
The current comp sci culture seems to discourage this in all but the lower level languages like C.
I use mainly VSCode these days though and Firefox, but even Unity game engine works just fine on this machine.
Any IDE I also throw at this machine works just fine. Only things that feel slow, are things that need a beefy GPU.
Probably depends on the IDE and the language. My impression is that newer computers (especially in the "consumer" / "general public" market) have especially improved efficiency. They're not much faster, but they last longer on smaller batteries.
My late 2013 15" (2.3 GHz / 16 GB RAM) works great with Pycharm for moderately sized projects. It's even usable for personal Rust projects (with the intellij-rust plugin).
For Rust it's somewhat slower than my i5-8500 desktop but not by much. For incremental compiles, I don't feel like I'm waiting around more. The i5 mainly wins when it can use all six cores.
It's however quite a bit faster than my work HP ProBook with an i5-8250U which is a much newer machine (2018 I'd say).
Aside from battery life, which is somewhat lesser, all in all the mac is a much, much better machine than the HP, especially for "creature comforts": gorgeous screen, no misaligned panels rubbing against my wrists, great trackpad, no random coil whine, inaudible fans unless it starts compiling for a while, no background noise on the headphone out, integrated optical output when I want to use my home stereo.
My work 2019 16-inch MacBook Pro actually doesn't feel that fast considering how fucking expensive it is.
Quiet and cool with about 11 hours of battery life when writing, reading or some simple productivity stuff.
Fast but loud and hot when doing anything else with about 3 hours of battery life. Even the Touch Bar (which I don’t hate, but I also don’t love) is uncomfortable to the touch.
It seems there is no in between. I’m generally happy with the machine, but I’m very interested in what’s next for the big MBP.
I've also had issues with the laptop waking from sleep, where it'd either hang for up to minutes, or just outright kernel panic. Big Sur seems to have fixed the kernel panics but waking from sleep still feels really slow.
I think from 2016-2019 was a rough era for the MacBook Pro when you factor in price for performance; still great machines, but they didn't feel as polished as the 2015 MBP or the 2020 M1's.
Edit: year banding.
Except for the keyboard. Been replaced three times. It's defective by design. Such a letdown.
We’re in a golden age of cpu improvements. A dual core 2016 mbp isn’t good enough for me any more.
Just wondering, don't those cores still have HyperThreading or such, resulting in actually more cores than just 2 physical ones ?
Finally sold the 2011 MacBook Air a few months ago for $300. I got so much value out of that laptop.
PS: apparently the quote is from 1997, go figure.
c - the speed of light, independent of the speed of the observer.
w - the speed of Windows, independent of the speed of the hardware.
So I actually think that Mac software will hold the performance edge for a long, long time.
It's fine to have an ARM version of Windows but there's no equivalently high-performance ARM chip to run it on. Unless you're talking about Bootcamp on Macs.
I have a vague tickle in my memory that both Intel and AMD have dabbled in ARM before.
Even if they don't assign large production volumes to it now, they could still have a design team working on it for a contingency plan.
https://en.wikipedia.org/wiki/AMD_K12
https://en.wikipedia.org/wiki/Zen_(first_generation_microarc...
Once Apple released M1, rumors of AMD ARM development started again https://www.techspot.com/news/87851-amd-rumored-working-arm-...
The fact that Apple writes much of their software for iOS and MacOS at the same time means much of it is designed to run on fairly light hardware.
I know we’re all stuck with bloated stuff like Slack and some of us with MS Office, but just go native where you can it reap the benefits of the platform.
I don't know about that, LLVM is getting slower with each new release too [1]. Same for Xcode: startup is very noticeably slower than a few years ago on the same machine. Starting into a debugging session for the first time is much slower (it used to be instant, now it's multiple seconds). The new build system in Xcode is most definitely slower than the old one, at least for projects with more than a handful compile targets. Etc etc etc... new software is only optimized to a point where performance doesn't hurt too much on the developer's machine.
[1] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
One nice thing is Swift is slow to build but quick at runtime.
Also, Apple’s buggy releases (which is tradition now[0]) didn’t really help.
0. Apple essentially stopped fixing bugs and they just release another buggy OS in a year or so with a new name and changes that break everything.
1. Garbage collection and minimum runtime
Garbage collection decreases memory efficiency, browsers need a certain minimum amount of resources to render a page, no matter how complicated leading to 500MB RAM text editors like Atom and worse once you open files. Similar problems plague Eclipse and IntelliJ which both often consume 1GB of RAM. The JVM often needs 150MB for an empty or perfectly optimized app.
2. Everything is an object with pointers
This is especially bad in Javascript where every object is basically a hashmap. This causes performance slowdowns because even something as simple as looking up a field is a pointer chase through several layers now. Raw numerical data may consume a lot of memory if you are not using typed arrays. Especially bad with ArrayList<Integer> in Java.
3. JIT
JIT compilers can only spend a certain amount of time on optimizations, which means JIT languages tend to either suffer from slow start up times or faster start up but less optimizations.
4. GUI complexity
Things like having animations and constantly recomputing layouts.
If you designed your processors for these things and made them fast at this, the only further source of slowdown is a lack of caring because you have already exhausted the unavoidable technical reasons. E.g. your processor is so fast, you write a naive algorithm that takes 5 seconds on the fastest computer available but then takes 20 seconds on an old computer.
Diffing a VDOM might fit here, but that's not really GUI-specific - just a combination of your earlier points.
What does that look like?
There is a reason Apple doesn’t do #1 and #3 and is moving away from #2 in their own code.
They are just inefficient ways of doing things. Designing a processor to support an inefficient mechanism will still lose out to a processor which doesn’t have to.
Look at multi-platform products like ms office and how slow they run on a Mac. I suspect because there is a translation layer to bridge win32 calls to Mac equivalents. And that seems like it would be point 5 on your list.