Google took one approach and Apple took another. 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. 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. 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. This may be more of a concern on Windows, but it's not a defect, just a characteristic of the application. There are times when I'd rather have a single tab crash than have the entire browser crash. 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. Google made a choice and they chose resiliency and fault tolerance over memory efficiency. 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 also has a more open plug-in/extension model. No, this is not poor programming, it’s a purposeful design choice that Google uses to improve resilience and fault tolerance.
#MAC OS SAFARI VS CHROME FULL#
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. Those positions go unfilled not because of the lack of applicants or funding, but because they cannot find enough applicants who meet their standards. Every one of these companies ALWAYS has openings, often in the hundreds, waiting to be filled by developers who meet their standards.
#MAC OS SAFARI VS CHROME SOFTWARE#
I have zero hesitation saying that by and large the software engineers working for all the big platforms including, but not limited to, Google, Microsoft, Amazon, Apple, Oracle, etc., are some of the best and most brilliant developers in the software development industry.
#MAC OS SAFARI VS CHROME CODE#
To all of those who think that the Google engineers who developed and work on Chrome are a bunch of misfits, try applying for a job at Google to show them how a "manly man" can code circles around their software development team members. The generic or obscure naming of these services makes finding all the places where a software application's full runtime stack is actually consuming memory a bit more difficult. There's absolutely nothing nefarious about this at all, it allows services that would otherwise be unmanageable to be better managed, services that listen for certain events to react accordingly, or simply to provide a faster launch of the primary app when it is loaded on demand. It's not unusual for the platform owner (and others) to run "helper" services inside surrogate hosting processes or with service names that aren't obvious to the casual observer to be associated with an application that is loaded on-demand. You have to be careful when comparing memory consumption of "first party" apps compared to third party apps.
Yeah, I also noticed that Safari consumes memory even when it's not loaded because it has some background services running either all of the time or at first invocation.
I, personally, set Safari and Chrome to open the same 5 tabs at start, and if you count ALL the Safari processes, it's actually MORE than Chrome. This article is being questioned by others saying the person who tested did not count the "Safari renderer" processes (which are rather large memory consumers) when counting Safari usage.
0 kommentar(er)
