7 ms·
Mine just arrived today and I'm blown away. After upgrading our app's dependency chain to run native arm64 builds (which took a bit of googling) webpack's incr
by yeldarb 5y ago
Mine just arrived today and I'm blown away.
After upgrading our app's dependency chain to run native arm64 builds (which took a bit of googling) webpack's incremental build time on our app is down to 116ms from 983ms on my 2016 Macbook Pro. Over 8x faster.
Our Tensorflow.js (webgl) models that previously ran about 8fps in the browser are now running at the camera's native 30fps framerate. (Similar to my desktop 2080ti.)
- Gigachad 5y agoAnd if its anything like my regular M1, it does that while remaining cold. I used a 2019 macbook pro and the thing would be roasting hot if you had docker running.
- skavi 5y agoThe regular M1 uses far less peak power than the M1 Pro/Max. They’re definitely still far more efficient than competitors though.
- asdff 5y agoCan you overclock the regular m1 then?
- saagarjha 5y agoI've gotten M1 Pro to heat up and require active cooling, unlike M1. It's certainly no space heater like my Intel Core i9 work laptop, but you can push it pretty hard.
- lordnacho 5y agoGot mine last week and not only is it faster, the power usage is crazy good. I took it to town for the first time yesterday, thought I'd do some coding between meetings for a few hours. Battery is still over 90%. I actually don't know what the thing sounds like with fans on, because it hasn't happened yet. My old machine from 2019 would have been down to half power at least, and the fans used to come on with just two monitors plugged in and not much workload.
- codeisawesome 5y agoI’ve wondered for a while if the fans coming on due to dual monitors is a software / driver issue that could be fixed by a patch. It would save me from buying a new machine right now.
- zuhsetaqi 5y agoIt’s because as soon as you plug in an external monitor, the dedicated GPU is used for the output and is responsible for the added heat
- sudhirj 5y agoThat part isn't a bug, though. It needs the dedicated GPU to push all those pixels, the native screen is already pretty dense. There was a bug where something would infinite loop on a non-standard resolution, think that was fixed.
- iknowstuff 5y agoI think I'm missing out as mine drops by a very pedestrian 10% an hour. WindowServer keeps using a cool 4% of the CPU at all times, even when nothing is running.
- grumpyprole 5y agoPerhaps you have some rogue process that is causing windows server to run at 4%?
- mmargerum 5y agoVisual studio code haha
- harshitaneja 5y agoI am not 2021 macbook pro's yet but on 2020 M1 VS Code doesn't have higher than usual impact on battery. Atleast I, with 7-8 active vscode windows throughout the day, couldn't notice.
- PikachuEXE 5y ago> After upgrading our app's dependency chain to run native arm64 builds Would you mind sharing your research results? I am getting one soon and I am in progress of drafting notes for stuff like migration & setup.
- SkyMarshal 5y agoI would like to see this too, it's my only hesitancy in getting one.
- yeldarb 5y agoIt was mostly stuff specific to our specific situation. We were still on node 12 because, until recently, Google Cloud Functions didn’t support anything newer. But when I installed it, I noticed it was running on x86 via Rosetta. So I upgraded to the latest node (17) which installed as native arm64. Almost everything “just worked” but there were build errors with installing: webpack, node-sass, gprc, and node-canvas. Webpack turned out to be an issue with node current (17) so downgrading to lts (which is currently 16) worked. That seems to have magically fixed the gprc build too. We weren't actually using node-sass anymore; so removed that dependency. Upgrading node-canvas to 2.8.0 and building from source (after installing its dependencies via homebrew) seems to have worked. All in all it took maybe 2 hours to follow all the rabbit holes. And our whole engineering team is going to move over to arm64 as soon as Apple can deliver their machines.
- BigJ1211 5y agoiirc node-sass was rewritten in dart and now you just need to use the package `sass` should work as a drop-in.
- capableweb 5y agoRather than switching hardware, you can also switch out the software to more efficient one. esbuild would make your builds go sub-ms even without needing a M1 CPU, also worth a try if you cannot switch to the newest hardware, so I guess this comment is for poor people.
- tdy_err 5y agoUnfortunately, ESbuild is not a drop-in replacement for Webpack either. So, the poor but lucky enough to rely on any plug-ins.
- matthewmacleod 5y agoesbuild is not simply “more efficient webpack” so that’s quite misleading.
- capableweb 5y agoGood thing I never said esbuild is "simply" "more efficient webpack". Parent was talking about build times, probably bulk of that is spent building JS, which you can plug in esbuild to handle instead.
- pistoriusp 5y agoESBuild doesn't polyfill, so it's _really_ not a decent replacement, unless you want to keep track of which JS object features are available in which targets and import those manually yourself?
- pistoriusp 5y agoWhy not both? I can honestly say that I didn't know how bad the 2019 MBP Intel CPUs are until I tried a M1. It's streets ahead. I don't think people will be moving away from webpack for awhile, but transpilation is often a very expensive part, and `swc` is very near to stable, and as a transpiler / polyfilling tool it's pretty fast.
- 5y ago
- Bishonen88 5y agoAre there any changes to be done in webpack itself to make the build process be quicker on a M1 machine?