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.
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?
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
In fact, LibreOffice does it too now so that it can benefit from the
same quick startup.
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.
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.
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? Wouldnt it be cool to have all these apps lurking in the
background, already running, chewing up memory and CPU cycles?
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.
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?
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.
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.
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!
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:33:39 |
| Calls: | 10,392 |
| Files: | 14,066 |
| Messages: | 6,417,253 |
