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

["Followup-To:" header set to comp.os.linux.advocacy.]
On 2025-03-29, Frank Slootweg <this@ddress.is.invalid> wrote:

Borax Man <rotflol2@hotmail.com> wrote:

["Followup-To:" header set to comp.os.linux.advocacy.]

>
  Ignored. This - and your response - is about both OSs.
>

On 2025-03-28, Frank Slootweg <this@ddress.is.invalid> wrote:

[...]
>

The problem with the "memory is there to be used" argument is when devs
just then use all your memory, because they think its spare.  But memory
that YOUR app takes, is less memory for other apps.

>
  The "memory is there to be used" argument is about that the *OS*
should 'use' (allocate) nearly all memory in the machine. Unallocated
memory is wasted memory. The argument is *not* about applications.
>

I've seen it used in the context of applications elsewhere, on multiple
occasions.

       Sure, use spare RAM
for caching, like Linux does, that is better than leaving it idle, but
you must be able to DROP the RAM when someone more important needs it.

>
  That's exactly what I described. If it's still allocated, for example
for a program whose previous invocation (i.e. process) has ended and
something needs memory, but there is no unallocated memory left, the
still allocated memory gets re-used, i.e. the program content gets
dropped. That's what any sane OS does. That's what BSD Unix did four
decades ago and what any modern OS still does.
>

The problem with this Windows approach, is these processes remain in
RAM, regardless of whether you need them or not. This IS a waste
because it blocks that RAM from being used for something where it could
deliver more of a benefit to the user.

>
  You're confusing a program with a process. You can drop a program
which is no longer in use, i.e. has no process associated with it, but
you can't drop a still 'active' (even if suspended) process (at least
not without the cooperation of the process/program).
>

If a program preloads itself, it is a running process, which remains
running, as you said, until it decides to terminate.  On the other hand,
caching by the kernel is more dynamic.

  Also, preloading slows boot
time.

>
  The article referenced in the OP doesn't give any details on this
particular 'Startup Boost task'. As it's a scheduled task, it can only
run *after* boot. so it doesn't slow *boot* time. Considering how other
similar tasks work, they normally run after login (no use having a
user-level program when there's no user) and are normally schedulled
with a delay. As noted in the article, the 'Startup Boost task' will not
be enabled on small (less than 8GB) memory systems and can be disabled
by an option in Word (Word only?).
>

       Swapping it out is counter productive.  The best optimisation is
slimming the program down.

>
  Yes, paging or swapping is the last resort when memory pressure is
(too) high.
>

Linux does the right thing here IMO.  Store what has been accessed from
the filesystem in RAM, but drop it when needed.

>
  Windows - and, as Paul noted, all other OSs - does the exact same
thing.

I may be a little out of date. I recall stuff like this back in the mid
2000's, so maybe I'm misreading how things are working today.

I do know, from practical experience, having the exact same laptop at
work with Window 10 and with Debian at home, that Windows in general
seems to perform worse.  There are other variables at play here, of
course.