jeffreytgilbert
About
- Username
- jeffreytgilbert
- Joined
- Visits
- 15
- Last Active
- Roles
- member
- Points
- 104
- Badges
- 0
- Posts
- 368
Reactions
-
Chrome is still a memory hog on macOS compared to Safari
Both are sandboxed and support background processes (web workers and service workers). I do remember that when the Chromium team worked Webkit to make Blink, one of the main reasons was isolated processes for tabs. I don’t recall if Webkit also added this or not, so I wouldn’t put a ton of stock into that argument.dewme said:I suspect Chrome is spinning up a full process for each tab while Safari is spinning up new threads within the same process to do the same thing.
No, this is not poor programming, it’s a purposeful design choice that Google uses to improve resilience and fault tolerance. Google also has a more open plug-in/extension model. Isolating plug-ins/extensions into their own process and memory address space within a tab keeps a poorly behaving, e.g., memory leaker, plug-in from bringing down the entire Chrome application if something goes wrong. Google made a choice and they chose resiliency and fault tolerance over memory efficiency. This makes perfect sense for their design intentions and as users it gives you a choice if you have to use or access certain sites or use certain plug-ins that are not as stable as you’d like. There are times when I'd rather have a single tab crash than have the entire browser crash. This may be more of a concern on Windows, but it's not a defect, just a characteristic of the application.
I've had to make these kinds of design choices and there have definitely been valid reasons for choosing out-of-process over in-process. Other reasons for running out-of-process include separating the lifetime of your server process from the lifetime of your clients, maintaining state between client sessions, and keeping your service/app running and doing things in the background. Yes, it costs more in memory consumption but most virtual memory based systems including Windows can handle low memory situations reasonably well, i.e., allowing the system to slow down rather than running out of memory and crashing. It's up to the designer to choose the model that best fits their design intentions and you'll find a mix of in-proc and out-of-proc services on all OSs that support these models. Google took one approach and Apple took another. No big deal in a world where you can have as many browsers on your computer as you would ever want to have.
If you “have” to use Chrome for a particular site it should not present a problem unless doing so requires you to open multiple tabs and you have so little memory that you get into a heavy paging situation. It’s not like you get a rebate or any material benefits from having a lot of free RAM just sitting there doing nothing.What is more likely to be the case is that the memory allocation and clean up schedules are significantly different between the two browsers. Additionally, Chrome has conditional logic to allow it to compile down to windows and linux binaries. Lastly, Chrome supports many more features and draft specs that Webkit does not. I help write web standards and work on browser dev and I can say from my experience, it takes much much longer to get features rolled out on Safari than on Chrome.I think you’re right that this is likely a design and approach choice, but it likely goes much deeper than process isolation. If anything, I would imagine process isolation to be better at keeping track of and releasing memory when it is finished. I’d love to see someone from the Chromium team and/or Safari team go over just what the root cause is for this, but my strongest suspicion is that Webkit calls more MacOS specific shared linked libraries and Chromium/Blink needing to be OS compatible roll their own functionality which simply doesn’t run as lean
-
Apple discontinues Music Memos, prompts users to migrate to Voice Memos
Wow. Very disappointed in these commenters so far.I had no idea this was even an Apple made app. I’m super bummed they’re pulling this app. It’s awesome. No frills interface with an automatic drum beat and/or bass you could toggle in and out easily. It figured out what chord you were playing and annotated it down like tabs/sheet music automatically. You can easily crop clips and most impressively share them via the share sheet super easily. It’s maybe not for everyone because everyone isn’t a musician, but that doesn’t mean it wasn’t a cool app. I use this all the time.
-
New Patreon project seeks to bring Linux to M1 Macs
Would love it if they just focused on the headless server aspects first since that would be immediately useful. Linux UI is such an incredibly small niche market compared to servers where linux marketshare is dominant and ARM chips are already amazon instances you can use -
Core Slack, Discord technology Electron now supports Apple Silicon
This is also not how any of this works. JavaScript code is absolutely compiled in the JIT compiler and run on a VM just as Java does. JavaScript is a very performant language that exposes hooks to native functionality via the V8 instance. It’s capable of running threaded and background processes and elegantly handling asynchronous tasks. Poorly written code exists in any language. This has absolutely no bearing on the 400mhz g3 vs 3ghz i5 chips.elijahg said:All the Electron stuff eats RAM and CPU cycles, it's hideously inefficient. Whoever though it would be a good idea to write desktop apps in JS should be removed to somewhere they can never inflict such horribleness on the world again. The ever higher levels of abstraction and interpreted vs compiled code is one of the reasons a program that once ran rapidly on a 400MHz G3 now requires a 3Ghz i5.What you might think of as slow javascript is typically the throttling done by browsers to keep the power usage down to a reasonable level. The same was true for Flash plugins and Java applets. Unmarried to the browser, JavaScript is incredibly fast by comparison. Also, as i said, it’s actually running a C code beneath the surface in the V8 engine.If Electron is slow, or bogs, it’s because of some goofy bottleneck they wrote into the code, not because of the language used and abstractions from bare metal.
-
Core Slack, Discord technology Electron now supports Apple Silicon
That’s not how any of this works.jimh2 said:Cross platform means less performance in every single case except for command line tools. If it is my choice it is native only.
