Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-11 > #17995 > unrolled thread

How To Speed Startup Of Microsoft Office? Have It Running All The Time!

Back to article view | Back to alt.comp.os.windows-11

Contents

  How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-27 21:30 +0000
    Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Joel <joelcrump@gmail.com> - 2025-03-27 17:31 -0400
      Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Paul <nospam@needed.invalid> - 2025-03-27 21:43 -0400
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! pothead <pothead@snakebite.com> - 2025-03-28 02:15 +0000
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-09 19:00 +0000
    Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! CrudeSausage <crude@sausa.ge> - 2025-03-27 22:07 -0400
      Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-28 04:49 +0000
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! vallor <vallor@cultnix.org> - 2025-03-28 05:20 +0000
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! CrudeSausage <crude@sausa.ge> - 2025-03-28 08:27 -0400
          Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-28 20:41 +0000
            Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! CrudeSausage <crude@sausa.ge> - 2025-03-28 17:35 -0400
    Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Peter Johnson <peter@parksidewood.nospam> - 2025-03-28 16:23 +0000
      Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-28 18:58 +0000
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Paul <nospam@needed.invalid> - 2025-03-28 17:00 -0400
          Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-28 20:39 +0000
            Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-28 21:25 +0000
              Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Paul <nospam@needed.invalid> - 2025-03-29 01:08 -0400
                Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-29 06:49 +0000
                  Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Paul <nospam@needed.invalid> - 2025-03-29 06:25 -0400
                    Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-30 06:21 +0000
                  Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-29 10:40 +0000
                Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Borax Man <rotflol2@hotmail.com> - 2025-03-29 12:05 +0000
                Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! vallor <vallor@cultnix.org> - 2025-03-29 13:14 +0000
                  Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Paul <nospam@needed.invalid> - 2025-03-29 11:46 -0400
                    Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-31 06:18 +0000
              Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-29 10:35 +0000
                Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-30 06:22 +0000
            Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Borax Man <rotflol2@hotmail.com> - 2025-03-29 00:55 +0000
              Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-29 11:17 +0000
                Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Borax Man <rotflol2@hotmail.com> - 2025-03-29 11:58 +0000
                  Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-30 14:39 +0000
        Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-28 20:40 +0000
          Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-29 11:26 +0000
            Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-29 22:21 +0000
              Re: How To Speed Startup Of Microsoft Office? Have It Running All The Time! Frank Slootweg <this@ddress.is.invalid> - 2025-03-30 14:23 +0000

Page 1 of 2  [1] 2  Next page →

#17995 — How To Speed Startup Of Microsoft Office? Have It Running All The Time!

Microsoft is trying to reduce the time it takes to start Office on
Windows, by moving part of the work to the time when you boot your PC
<https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.

What a wonderful idea: make an app start faster by making your machine
take longer to boot. What if other major Windows apps did the same
thing? Wouldn’t it be cool to have all these apps lurking in the
background, already running, chewing up memory and CPU cycles?

[toc] | [next] | [standalone]

#17996

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>Microsoft is trying to reduce the time it takes to start Office on
>Windows, by moving part of the work to the time when you boot your PC
><https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>
>What a wonderful idea: make an app start faster by making your machine
>take longer to boot. What if other major Windows apps did the same
>thing? Wouldn’t it be cool to have all these apps lurking in the
>background, already running, chewing up memory and CPU cycles?


This would be a good example of why I used LO under Windows, and
ignored Office.

-- 
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent.  States are
liable for denying needed abortions, e.g. TX.

[toc] | [prev] | [next] | [standalone]

#18002

On Thu, 3/27/2025 5:31 PM, Joel wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 
>> Microsoft is trying to reduce the time it takes to start Office on
>> Windows, by moving part of the work to the time when you boot your PC
>> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>>
>> What a wonderful idea: make an app start faster by making your machine
>> take longer to boot. What if other major Windows apps did the same
>> thing? Wouldn’t it be cool to have all these apps lurking in the
>> background, already running, chewing up memory and CPU cycles?
> 
> 
> This would be a good example of why I used LO under Windows, and
> ignored Office.
> 

Metro Apps have a different state diagram than Win32 programs.
If you look in Task Manager, you can sometimes already see
something sitting there in the Suspended state (it's like a TSR).

   https://i.sstatic.net/lrTZh.png

You need to find a more detailed version of that diagram, because
below the "Suspended" ball, is a "Terminated" ball. If
MSWord had gone to the "Suspended" state, and some other
activity on the computer needed a lot of RAM, the Suspended
APP can Terminate and the resources get harvested.

But otherwise, the image can sit in RAM, waiting for a time
to be re-invoked. And that shortens the load time, because
it is already there.

What TheVerge article is telling you, is the state diagram
likely has more sticks added to it. Previously, the loader
would have loaded an App right to the Running state, and
it would have taken time for the App to move to the Suspended state
(because "there was nothing to do"). The change they
are proposing, would be for the loader to load an App
right to the Suspended state, so that when it is actually
invoked again (by the user this time), it will move from Suspended
to Running faster.

   Paul

[toc] | [prev] | [next] | [standalone]

#18004

On 2025-03-28, Paul <nospam@needed.invalid> wrote:
> On Thu, 3/27/2025 5:31 PM, Joel wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> 
>>> Microsoft is trying to reduce the time it takes to start Office on
>>> Windows, by moving part of the work to the time when you boot your PC
>>> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>>>
>>> What a wonderful idea: make an app start faster by making your machine
>>> take longer to boot. What if other major Windows apps did the same
>>> thing? Wouldn’t it be cool to have all these apps lurking in the
>>> background, already running, chewing up memory and CPU cycles?
>> 
>> 
>> This would be a good example of why I used LO under Windows, and
>> ignored Office.
>> 
>
> Metro Apps have a different state diagram than Win32 programs.
> If you look in Task Manager, you can sometimes already see
> something sitting there in the Suspended state (it's like a TSR).
>
>    https://i.sstatic.net/lrTZh.png
>
> You need to find a more detailed version of that diagram, because
> below the "Suspended" ball, is a "Terminated" ball. If
> MSWord had gone to the "Suspended" state, and some other
> activity on the computer needed a lot of RAM, the Suspended
> APP can Terminate and the resources get harvested.
>
> But otherwise, the image can sit in RAM, waiting for a time
> to be re-invoked. And that shortens the load time, because
> it is already there.
>
> What TheVerge article is telling you, is the state diagram
> likely has more sticks added to it. Previously, the loader
> would have loaded an App right to the Running state, and
> it would have taken time for the App to move to the Suspended state
> (because "there was nothing to do"). The change they
> are proposing, would be for the loader to load an App
> right to the Suspended state, so that when it is actually
> invoked again (by the user this time), it will move from Suspended
> to Running faster.
>
>    Paul

Paul you are and have been one of the most knowledgeable posters to Usenet.
Thank you.

-- 
pothead
Liberalism Is A Mental Disease
Treat it accordingly
<https://www.dailymail.co.uk/health/article-14512427/Doctors-reveal-symptoms-Trump-Derangement-Syndrome-tell-youve-got-it.html>

[toc] | [prev] | [next] | [standalone]

#18377

Paul <nospam@needed.invalid> wrote at 01:43 this Friday (GMT):
> On Thu, 3/27/2025 5:31 PM, Joel wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> 
>>> Microsoft is trying to reduce the time it takes to start Office on
>>> Windows, by moving part of the work to the time when you boot your PC
>>> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>>>
>>> What a wonderful idea: make an app start faster by making your machine
>>> take longer to boot. What if other major Windows apps did the same
>>> thing? Wouldn’t it be cool to have all these apps lurking in the
>>> background, already running, chewing up memory and CPU cycles?
>> 
>> 
>> This would be a good example of why I used LO under Windows, and
>> ignored Office.
>> 
>
> Metro Apps have a different state diagram than Win32 programs.
> If you look in Task Manager, you can sometimes already see
> something sitting there in the Suspended state (it's like a TSR).
>
>    https://i.sstatic.net/lrTZh.png
>
> You need to find a more detailed version of that diagram, because
> below the "Suspended" ball, is a "Terminated" ball. If
> MSWord had gone to the "Suspended" state, and some other
> activity on the computer needed a lot of RAM, the Suspended
> APP can Terminate and the resources get harvested.
>
> But otherwise, the image can sit in RAM, waiting for a time
> to be re-invoked. And that shortens the load time, because
> it is already there.
>
> What TheVerge article is telling you, is the state diagram
> likely has more sticks added to it. Previously, the loader
> would have loaded an App right to the Running state, and
> it would have taken time for the App to move to the Suspended state
> (because "there was nothing to do"). The change they
> are proposing, would be for the loader to load an App
> right to the Suspended state, so that when it is actually
> invoked again (by the user this time), it will move from Suspended
> to Running faster.
>
>    Paul


So, it's like when files are stored in RAM, but cleared if the RAM
requirement gets too high?
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#18003

On 2025-03-27 5:30 p.m., Lawrence D'Oliveiro wrote:
> Microsoft is trying to reduce the time it takes to start Office on
> Windows, by moving part of the work to the time when you boot your PC
> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
> 
> What a wonderful idea: make an app start faster by making your machine
> take longer to boot. What if other major Windows apps did the same
> thing? Wouldn’t it be cool to have all these apps lurking in the
> background, already running, chewing up memory and CPU cycles?

This isn't new. They've been doing this with Internet Explorer back in 
the day as well as Microsoft Office. In fact, LibreOffice does it too 
now so that it can benefit from the same quick startup.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]

#18005

On Thu, 27 Mar 2025 22:07:27 -0400, CrudeSausage wrote:

> In fact, LibreOffice does it too now so that it can benefit from the
> same quick startup.

I have no LibreOffice processes running in the background on my Linux 
system.

[toc] | [prev] | [next] | [standalone]

#18006

On Fri, 28 Mar 2025 04:49:13 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vs59o9$1vo73$1@dont-email.me>:

> On Thu, 27 Mar 2025 22:07:27 -0400, CrudeSausage wrote:
> 
>> In fact, LibreOffice does it too now so that it can benefit from the
>> same quick startup.
> 
> I have no LibreOffice processes running in the background on my Linux
> system.

I don't either.

I started LibreOffice Writer, and saw the processes.

I exited Writer, and the processes went away.

The only "libre" I have constantly running is "librenms", which I
use to monitor my network -- and actually, that's just php-fpm
instances that are used by nginx.

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.14.0 Release: Mint 22.1 Mem: 258G
   "Both of his feet are firmly planted in the air."

[toc] | [prev] | [next] | [standalone]

#18011

On 2025-03-28 00:49, Lawrence D'Oliveiro wrote:
> On Thu, 27 Mar 2025 22:07:27 -0400, CrudeSausage wrote:
> 
>> In fact, LibreOffice does it too now so that it can benefit from the
>> same quick startup.
> 
> I have no LibreOffice processes running in the background on my Linux
> system.

Sure, but in Windows, LibreOffice gives you the option, at installation 
time, to have the software load at startup just like Microsoft Office.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]

#18021

On Fri, 28 Mar 2025 08:27:53 -0400, CrudeSausage wrote:

> On 2025-03-28 00:49, Lawrence D'Oliveiro wrote:
>>
>> On Thu, 27 Mar 2025 22:07:27 -0400, CrudeSausage wrote:
>> 
>>> In fact, LibreOffice does it too now so that it can benefit from the
>>> same quick startup.
>> 
>> I have no LibreOffice processes running in the background on my Linux
>> system.
> 
> Sure, but in Windows, LibreOffice gives you the option, at installation
> time, to have the software load at startup just like Microsoft Office.

I wonder why it needs it on Windows?

To make up for Windows’ low performance? Surely not!

[toc] | [prev] | [next] | [standalone]

#18025

On 2025-03-28 4:41 p.m., Lawrence D'Oliveiro wrote:
> On Fri, 28 Mar 2025 08:27:53 -0400, CrudeSausage wrote:
> 
>> On 2025-03-28 00:49, Lawrence D'Oliveiro wrote:
>>>
>>> On Thu, 27 Mar 2025 22:07:27 -0400, CrudeSausage wrote:
>>>
>>>> In fact, LibreOffice does it too now so that it can benefit from the
>>>> same quick startup.
>>>
>>> I have no LibreOffice processes running in the background on my Linux
>>> system.
>>
>> Sure, but in Windows, LibreOffice gives you the option, at installation
>> time, to have the software load at startup just like Microsoft Office.
> 
> I wonder why it needs it on Windows?
> 
> To make up for Windows’ low performance? Surely not!

LibreOffice definitely feels a lot more bloated in Windows than it does 
in Linux.

-- 
God be with you,

CrudeSausage
John 14:6

[toc] | [prev] | [next] | [standalone]

#18016

On Thu, 27 Mar 2025 21:30:43 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>Microsoft is trying to reduce the time it takes to start Office on
>Windows, by moving part of the work to the time when you boot your PC
><https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>
>What a wonderful idea: make an app start faster by making your machine
>take longer to boot. What if other major Windows apps did the same
>thing? Wouldn’t it be cool to have all these apps lurking in the
>background, already running, chewing up memory and CPU cycles?

Look under the Startup Apps in the task manager and you'll find a
whole load of things that run at startup. Mine includes the Dymo label
printer app, Copernic desktop search and the app that monitors the
battery backup.

[toc] | [prev] | [next] | [standalone]

#18017

Peter Johnson <peter@parksidewood.nospam> wrote:
> On Thu, 27 Mar 2025 21:30:43 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
> 
> >Microsoft is trying to reduce the time it takes to start Office on
> >Windows, by moving part of the work to the time when you boot your PC
> ><https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
> >
> >What a wonderful idea: make an app start faster by making your machine
> >take longer to boot. What if other major Windows apps did the same
> >thing? Wouldn?t it be cool to have all these apps lurking in the
> >background, already running, chewing up memory and CPU cycles?
> 
> Look under the Startup Apps in the task manager and you'll find a
> whole load of things that run at startup. Mine includes the Dymo label
> printer app, Copernic desktop search and the app that monitors the
> battery backup.

  Exactly, nothing new. But perhaps for Lawrence's - apparently - stone
age OS, which doesn't know how to have such 'Startup Boost' (and
similar) programs without "chewing up memory and CPU cycles", when
they're "lurking in the background, already running" [1]. That problem
was already solved at least some four decades ago.

[1] Of course his OS *can* do that. After all, it's Unix-like, isn't it?

[toc] | [prev] | [next] | [standalone]

#18018

On Fri, 3/28/2025 2:58 PM, Frank Slootweg wrote:
> Peter Johnson <peter@parksidewood.nospam> wrote:
>> On Thu, 27 Mar 2025 21:30:43 -0000 (UTC), Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote:
>>
>>> Microsoft is trying to reduce the time it takes to start Office on
>>> Windows, by moving part of the work to the time when you boot your PC
>>> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
>>>
>>> What a wonderful idea: make an app start faster by making your machine
>>> take longer to boot. What if other major Windows apps did the same
>>> thing? Wouldn?t it be cool to have all these apps lurking in the
>>> background, already running, chewing up memory and CPU cycles?
>>
>> Look under the Startup Apps in the task manager and you'll find a
>> whole load of things that run at startup. Mine includes the Dymo label
>> printer app, Copernic desktop search and the app that monitors the
>> battery backup.
> 
>   Exactly, nothing new. But perhaps for Lawrence's - apparently - stone
> age OS, which doesn't know how to have such 'Startup Boost' (and
> similar) programs without "chewing up memory and CPU cycles", when
> they're "lurking in the background, already running" [1]. That problem
> was already solved at least some four decades ago.
> 
> [1] Of course his OS *can* do that. After all, it's Unix-like, isn't it?
> 

A number of the SVCHOST, don't typically use cycles. You can check
that with Process Explorer. If elevated as Administrator, it can
do profiling of processes, and it shows a cycle count for the
item you're tracing. And many SVCHOST are zero. The ones like
Windows Update support, would not be zero.

Quiet processes still use memory. A suspended Metro App could still
take up memory. Once it is in the run state, the event loop will be
running, and any time the OS sends an event, the event loop "eats it"
and that takes a few cycles at a minimum.

The OS has a Memory Compressor (it can only be seen in Process Explorer,
not in Task Manager). If under extreme memory pressure,
the MS Office Metro.App could have its actual (occupied) memory
compressed to half the size.

The OS does have a few tricks, to conserve resources.

But also at times, is a pig. Nobody is perfect :-)
There is still lots of room for improvements.

Windows and Linux and FreeBSD and MacOS are all "preemptive multitasking"
OSes. Just as Unix was. That makes a world of difference to runtime
reliability. No longer do we put up with two crashes per day. Even the
RAM electrical signal integrity today, is finally "good" and not
"utter crap" like the old days.

   Paul

[toc] | [prev] | [next] | [standalone]

#18019

Paul <nospam@needed.invalid> wrote:
> On Fri, 3/28/2025 2:58 PM, Frank Slootweg wrote:
> > Peter Johnson <peter@parksidewood.nospam> wrote:
> >> On Thu, 27 Mar 2025 21:30:43 -0000 (UTC), Lawrence D'Oliveiro
> >> <ldo@nz.invalid> wrote:
> >>
> >>> Microsoft is trying to reduce the time it takes to start Office on
> >>> Windows, by moving part of the work to the time when you boot your PC
> >>> <https://www.theverge.com/news/637469/microsoft-office-speed-boost-faster-launch>.
> >>>
> >>> What a wonderful idea: make an app start faster by making your machine
> >>> take longer to boot. What if other major Windows apps did the same
> >>> thing? Wouldn?t it be cool to have all these apps lurking in the
> >>> background, already running, chewing up memory and CPU cycles?
> >>
> >> Look under the Startup Apps in the task manager and you'll find a
> >> whole load of things that run at startup. Mine includes the Dymo label
> >> printer app, Copernic desktop search and the app that monitors the
> >> battery backup.
> > 
> >   Exactly, nothing new. But perhaps for Lawrence's - apparently - stone
> > age OS, which doesn't know how to have such 'Startup Boost' (and
> > similar) programs without "chewing up memory and CPU cycles", when
> > they're "lurking in the background, already running" [1]. That problem
> > was already solved at least some four decades ago.
> > 
> > [1] Of course his OS *can* do that. After all, it's Unix-like, isn't it?
> 
> A number of the SVCHOST, don't typically use cycles. You can check
> that with Process Explorer. If elevated as Administrator, it can
> do profiling of processes, and it shows a cycle count for the
> item you're tracing. And many SVCHOST are zero. The ones like
> Windows Update support, would not be zero.

  Exactly. In any sane OS, a suspended/blocked/<whatever> process
doesn't use any CPU cycles, period.

> Quiet processes still use memory. A suspended Metro App could still
> take up memory.

  A lesson (not to you) from the very old days: Memory is there to be
'used'. You didn't buy it for nothing. Memory is allocated to all kinds
of things, but that doesn't mean it's in active use and doesn't mean
that it can not be freed/re-used when needed.

  Ever since BSD Unix, memory could be filled upto 90%  (minfree?) and
that was A Good Thing (TM).

  On my Windows systems, Task Manager normally reports a 'Memory usage'
of some 50%, but I assume/hope it's 'lying' and doesn't include memory
which is allocated but not actually in-use by a process. I.e. I start
and exit an editor. The memory used by that program is not released. Is
it counted in 'Memory usage' or not?

>		  Once it is in the run state, the event loop will be
> running, and any time the OS sends an event, the event loop "eats it"
> and that takes a few cycles at a minimum.

  Of course, if a process has to do something, it uses CPU, but when
it's 'idle', it doesn't.

> The OS has a Memory Compressor (it can only be seen in Process Explorer,
> not in Task Manager). If under extreme memory pressure,
> the MS Office Metro.App could have its actual (occupied) memory
> compressed to half the size.
>
> The OS does have a few tricks, to conserve resources.
> 
> But also at times, is a pig. Nobody is perfect :-)
> There is still lots of room for improvements.

  Yes, when the memory pressure becomes too high, any system will
experience trashing, but an idle process - which is the topic of the
(non-)discussion - should present no problem. Can't fit it? Page/swap it
out. 'Problem' solved.

[...]

[toc] | [prev] | [next] | [standalone]

#18024

Linux can use memory for filesystem cache that can be quickly dumped and 
reallocated for regular application use. This is why the memory display 
distinguishes between “free” memory and “available” memory -- the latter 
includes both free memory and cache space.

Windows isn’t so good at this, let’s face it.

[toc] | [prev] | [next] | [standalone]

#18032

On Fri, 3/28/2025 5:25 PM, Lawrence D'Oliveiro wrote:
> Linux can use memory for filesystem cache that can be quickly dumped and 
> reallocated for regular application use. This is why the memory display 
> distinguishes between “free” memory and “available” memory -- the latter 
> includes both free memory and cache space.
> 
> Windows isn’t so good at this, let’s face it.
> 

I don't know if the message is getting through yet,
but Windows has every feature Linux has. Why do you
think they hired 7000 developers ? They're running
Xerox machines all day long. the task bar descends
just like MacOS. What a coincidence.

Windows has System Read cache and System Write cache.
It has System Read cache in Win2K. System Write cache
came later.

The System Read cache is like every other implementation.
Unix had it, MacOS had it (on my G4 in 10.3), Linux has it,
Windows has it (since Win2K at least). At the time this
happened, all the OS companies were running their Xerox
machines and copying shit from one another. In all of them,
memory is not booked, and as Frank would note, "memory is to be used",
and the ideal case happens with System Read caches, on all systems.
They give the memory back, any time you need it.

System Write caches are booked. And they have percentage
limits on how much memory they will book. System Write caches
are a non-ideal case, and if you're good, you can "jam" an OS
such that it freezes. I managed to do that once, realized
the mistake I'd made, but I couldn't type fast enough to
stop it :-/ OS froze. Had to reboot.

Use a little imagination please. Come out of your cave.

   Paul

[toc] | [prev] | [next] | [standalone]

#18039

On Sat, 29 Mar 2025 01:08:30 -0400, Paul wrote:

> I don't know if the message is getting through yet,
> but Windows has every feature Linux has. Why do you think they hired
> 7000 developers ?

Mainly to get in each other’s way, judging from their (lack of) 
productivity.

> Windows has System Read cache and System Write cache.
> It has System Read cache in Win2K. System Write cache came later.
> 
> The System Read cache is like every other implementation.

Doesn’t seem to be. The usage of RAM in the cache seems to interfere with 
regular applications’ use of RAM, in a way that doesn’t happen under 
Linux.

[toc] | [prev] | [next] | [standalone]

#18042

On Sat, 3/29/2025 2:49 AM, Lawrence D'Oliveiro wrote:
> On Sat, 29 Mar 2025 01:08:30 -0400, Paul wrote:
> 
>> I don't know if the message is getting through yet,
>> but Windows has every feature Linux has. Why do you think they hired
>> 7000 developers ?
> 
> Mainly to get in each other’s way, judging from their (lack of) 
> productivity.
> 
>> Windows has System Read cache and System Write cache.
>> It has System Read cache in Win2K. System Write cache came later.
>>
>> The System Read cache is like every other implementation.
> 
> Doesn’t seem to be. The usage of RAM in the cache seems to interfere with 
> regular applications’ use of RAM, in a way that doesn’t happen under 
> Linux.
> 

It seems to be implemented as some sort of unified cache.

https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching

125516 MB      22.333757 sec     # Malloc test after a reboot
125405         34.227482         # Malloc after System Read Cache full (system read cache gets purged by this...)
125415         26.925629         # Subsequent runs of malloc64.exe, system read cache empty
125419         25.530308
125370         24.816107
125321         25.015528

There isn't zero overhead on the memory management.

*******

I did the same test on Linux.

The top command has columns like

TOTAL   FREE   USED    BUFF/CACHE

and the first quantity equals the sum of the other three.

This implies, at least from a book-keeping perspective, it
works the same as Windows.

The malloc.c code differs between the Windows and Linux versions,
in the time measurement code. Not in the malloc and memory filling parts.
And this is the result of testing on Linux.

120144 MB     43.035967 sec      # Malloc test after a reboot
120144 MB     43.139267 sec      # Malloc after System Read Cache full (system read cache gets purged by this...)

It's true that the behavior looks better, but... Linux is slower.

During compile, the same optimization level is used in both environments.

The reason the memory amount is lower, is the malloc-linux program
has to be stopped before the OOM-killer is triggered. The same code
on Windows, simply exits when the last malloc call fails to allocate
memory.

   Paul

[toc] | [prev] | [next] | [standalone]

#18067

On Sat, 29 Mar 2025 06:25:55 -0400, Paul wrote:

> The reason the memory amount is lower, is the malloc-linux program has
> to be stopped before the OOM-killer is triggered. The same code on
> Windows, simply exits when the last malloc call fails to allocate
> memory.

You know you can configure the memory-allocation algorithm on Linux, 
right?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.comp.os.windows-11

csiph-web