|
It has to upload all of your personal data to MS. That's what takes it so long.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Where is the outrage?
I hope they are happy with who I am. I'm positively the most boring person you ever would want to know.
|
|
|
|
|
first thing to do on windows is disable superfetch service, especially if you have SSD, but even on spinners it would be no longer useful [even if it did work properly].
- at startup it's supposed to load up as many of your "often used apps" into memory as can fit, problem is it's nearly always loading up important windows apps really stupid crap such as wordpad (which for me I might use once every 2 years or less) Of course it kicks out that crap when you use something like visual studio starts up, but guess what happens when you exit vs...
- theory is sound, saves loading the apps later [when used] from slow hard disks, but today, even if you are on spinners which in this case are too way fast enough, it's irrelevant
- yet MS still includes and enables it even on win 10, even if you have SSD.
- It's useless, it actually slows you down!
something else I noticed:
* windows: when I left my PC on doing nothing (say a lunch break) the hdd light would regularly flicker, every few seconds briefly and about once a minute longer for a second or more (also network activity at about the same rate)
... what is it doing??
- not saying it's all spying (this was in win 7 too), but there is that
- yes background maintenance, but why does it reload it and [re]perform the checks every time?
* linux: leave it alone and it barely ever flickers, and way less net traffic. [smart enough to leave it loaded if nothing else requires the mem, smart enough to leave it's last-run data loaded.]
short explanation: windows inner core design and yes: even a lot of it's actual kernel code, is still based on hardware from the 1970's, windows 10 is NOT a new OS, it's crap on top of an old one (that relies almost exclusively on new hardware base speed (not code) to be "better than before.")
Summary: don't blame windows for being bad, instead blame it for being VERY outdated.
for those that want something to picture:
steam engines built 100+ years ago still work fine, doesn't mean they should be [given a fresh coat of paint and] used for hauling cross continental passengers and freight though does it?
... this is exactly what you have with windows.
Message Signature
(Click to edit ->)
|
|
|
|
|
Gee, if all what you write were correct and true 
I wonder: How can you see that wordpad, which you might use once every 2 years, is prefetched?
I wonder: How will the computer be slowed down when overwriting pages and page table entries referring to some other application (such as wordpad) as compared to overwriting zeored entries?
I wonder: Which hardware from the 1970's affects the Windows design? And in which ways? It can well be argued that the Windows 3.x software memory management was very strongly influenced by the 386 hardware MMS, and at lest on the design level could have been put onto the 386 more or less directly. But at that time, MS was striving to make Windows available on all sorts of processors, so they abandoned essential parts of the 386 MMS in favor of a single, flat memory model that was generally available on all relevant CPUs.
What is true is that MS has taken backwards compatibility to extremes (in my opinion): Read Raymond Chen's selections of blogposts from The New Old Thing[^] - quite a few of the (sometimes rather funny) stories he tells have to do with backwards comptatibilty. In contrast to people writing open software in their spare time, MS has to support their existing customer base. As a programmer, I wished that 32 bit Windows would have a thoroughy cleaned-up API (from the 16 bit version), since it couldn't be 100% compatible anyway. We didn't get that - but we got thousands of Windows applications ported from 16 to 32 bits in a few months, because MS decided to bring the API changes to a minimum, to simplify porting. From a marketing point of view (and even more the wiew of independent software vendors making Windows apps, rather than MS itself), I can fully defend that decision. What goes on under the hood is a completely different matter.
|
|
|
|
|
Member 7989122 wrote: wonder: How can you see that wordpad, which you might use once every 2 years, is prefetched?
well, look in \windows\prefetch, and there it is. I even see sidebar - which I never used and in fact disabled years ago. I'm really glad ms has my best intentions in mind loading those important apps.
Member 7989122 wrote: wonder: How will the computer be slowed down when overwriting pages and page table entries referring to some other application (such as wordpad) as compared to overwriting zeored entries?
Umm, it's slowed down because it's loading that say wordpad from the disk into memory, and when I exit visual studio, it loads it back again
and hence, superfetch is useless. even if you have spinners it really should be disabled. If you have SSD it's almost important to disable it. (and despite some claims it does not auto disable if it sees SSD - that's just another myth.)
Member 7989122 wrote: I wonder: Which hardware from the 1970's .... , so they abandoned essential parts of the 386 MMS in favor of a single, flat memory model that was generally available on all relevant CPUs.
glad you agree with me: "a single, flat memory model ... all relevant CPU's" which includes the 186, 286, 386..., and are they not from the 70's? so yes, it's [your words] using a single model that supports all architectures thus including 70's and thus not able to make use of optimizations of later CPU's.
yes, sure, it's for backwards compatibility, and yes for backward compat, but really what's the point? there's features of w7 and beyond the 80286 will not handle, so why leave an outdated major core function that by design of other parts of the system is actually irrelevant?? (and how can ms claim w10 is an entirely new OS when it's core is that old?).
anyway just glad we and agree and your input to further detail it for others.
Message Signature
(Click to edit ->)
|
|
|
|
|
Quote: "a single, flat memory model ... all relevant CPU's" which includes the 186, 286, 386..., and are they not from the 70's?
If you had been bitching about the segmented memory of the '86 (all the way back to the 8086), I could have agreed with you. But that particular MMS mechanism that was gradually made more and more complex, from the 8086 and upwards to the 386, is what is particular to that family - and that was abondoned by MS. Well, there is no real way to turn off the segmentation, so what they do is to define a single 4 GB (in 32 bit mode) hardware code segment, a single 4 GB hardware stack segment and a single 4 GB harware code segment and put them on top of each other, and then build a software mechanism for doing a very similar segmentation. (Btw: 286 and 386 are designs of the 1980s, not the 1970s, and there never was any 186 Windows.)
If you are talking about flat memory models: "thus not able to make use of optimizations of later CPU's" - I wonder what you are referring to here - which mechanisms that is. And I wonder how other OSes make use of these mechanisms in ways that Windows doesn't. I know of several single-architecture OSes that make use of mechanisms particular to that specific architecture, but that is much more in the area of interrupt and exception handling than in memory management.
Flat, unsegmented memory certainly did not arrive in the 1970s - it more or less stems from the days of ENIAC. In that sense you could say that all OSes have their roots in hardware from the 1940s. If that is too far back for you: Another widespread OS is based on a 1965 vintage 12-bit architecture: It may well be argued that this architecture is the root of its very strong single-isolated-segment paradigm: Splitting up 4096 words into a collection of separate but cooperating segments would be rather impractical. The segments simply had to operate alone, and processes couldn't access more than its own segment, because there wasn't room in memory for two segments at a time. Today, there are workarounds, that definitely have the appearance of Workarounds, for this: The main paradigm is still that a a process has a single segment, as a single isolated box, communicating through flat files only - even for such a basic concept as synchronization.
Now I checked windows\prefetch at this machine, and you are right: There is a file named Wordpad.exe-...pf there. But first: It hasn't even been read, for about three months (and occasionally, I do start WordPad - last time may have been three months ago). Second: The file is 21 kB, while the "real" Wordpad.exe is almost 4,5 MB. So the prefetch directory most certainly does not hold the full .exe file - most likely some sort of metadata. In any case: Presence on disk does not show that the entire executable file is loaded into RAM, as you say.
IF it was, it might slow down the boot up time by a few MS. A SATA-600 disk can deliver 4,5 MB from a single NTFS extent in something like 10 ms. If that 10 ms slowdown bothers you a lot, feel free to be bothered a lot. (Anyway, I doubt that is actully happens). When you leav VS, and claim that is it reloaded again: Disk I/O is managed by DMA circuits. The CPU starts the transfer, and then goes on performing other tasks while the transfer is taking place. If you, within 10 ms after having closed VS start another huge file access on the same disk, it may have to wait for whatever remains of that 10 ms transfer. Feel free to feel bothered by that as well - and again, I doubt very much that Wordpad is actually read into RAM. Even if you had actually been using WordPad immediately before starting VS: Unless you are short on RAM, with noticable paging, chances are way above zero that the WordPad pages were still present in RAM with no need to read them in again.
I strongly suspect that there are aspects of the superfetch mechanism that you have not fully grasped. Either not at all, or misunderstood.
|
|
|
|
|
too much to read
whatever on the memory management, MS still supports ancient [in fact incompatable] processor architectures, far from optimal. It's that simple!
... oh yes superfetch does slow you down, I start VS, it loads it into mem, exit VS, it loads some useless crap into mem, I start VS again, AGAIN it has to load it from disk AGAIN. I'm not griping about the loading of the useless crap, it's the forced RE-LOAD of the stuff I do want (i.e. when I go back into VS).
Standard caching practice is to leave whatever was there last (i.e. in this case VS) until space is required, not burn it and load up some other crap just for the sake of it.
Now do you get it? Even if it's pico seconds there is NO way doing what ms does could NOT BE SLOWER. Again it's that simple.
Member 7989122 wrote: I strongly suspect that there are aspects of the superfetch mechanism that you have not fully grasped. Either not at all, or misunderstood.
odd you should say that as it was you who asked me how I could find out what superfetch was caching, the answer [that I gave you] was pretty simple was it not, seemed you were the one unaware of this.
if you had bothered to learn at least a little about the technical details [not just the the ms bullshit] you wouldn't have had to ask me such a silly question.
Sorry, but you've attempted to insult me twice now, and it's twice I've proven you wrong.
Ask me to learn more??? It's you clearly demonstrating the lack of knowledge and understanding.
Ever written microcode? Ever written an operating system from scratch?
You're welcome to come back and discuss further when you've caught up to me, until then no point continuing further; goodbye.
Message Signature
(Click to edit ->)
|
|
|
|
|
Sorry, pal, you are not getting through!
Even from the start: That "too much to read" is a clear announcement: "I choose to ignore those facts that I choose to ignore". Fair enough, but that does affect your credibility, if you like it or not.
I observe that you do not want to go in details about your alleged limitations caused by the old Intel processors memory model, nor the claimed extensions not exploited by Windows. You imply: well I really have noting more to be said about that - forget it!
You have brought no more "proof" of superfetch loading of irrelevant applications into memory, except you have seen some similarly named metadata disk file in some disk directory. Great "proof, isn't it?
No, I do not "get it", that "useless crap" is loaded. Firt: I don't se it happen. Second: Sometimes there are resons for things being done. I am responsible for a toolchain management system where I thousands of times (well, at least several hundreds of times) have had to explain to its users why it is necessary to re-read the information from the file system, again and again: Something might have changed. Without exception they leave my boot with an "OK, so that's why! ..." Sure, well behaved applications announce changes, but we have a load of applications that do not, so there you have it!
There are two levels of complaint: The first one is "I do not want my PC to do this - it slows it down"
The second level is: "Look here: Now I have disabled function X, and my PC complets its tasks i X.yy second. Let's try again with function X enables: it completes in Z.yy seconds. It is repeatable: We can run it five fimes with X enabled, five times with X disabled, and is consistently a.xx seconds faster with X disabled."
My problem with such claims is that some obstacle always makes it impossible to compare the two alternatives, "changing the build plans to the other alernative is too much work, we know that it is how we say it is!". That is not neceessarily at the outset, but when the "obvious" differences do not show up, the explanations why they are still there, to full extent, even if the comparative test didn't reveal them because it was not properly done ... Right!!
There is no indication whatsoever for WordPad loading 4.5 MB into my RAM of my machine. Your "proof" to the contrary is a disk file which on my machine is half a percent of that size and hasn't been read for three months. What proof!
Actually, I have been microcoing a 2901 procssor. And I have designed the interrupt handling system as hte core of an ARM based system. So I know what system software is about. And then I also know that even though you may be competent to control the signals going to various hardware circuits. it certainly doesn't prove that you are an expert of, or even understand the basics of, hight level buffer management, memory management and the like.
So: I feel free to turn you or anyone else down when you make statements in an area that you do not master, statements that you cannot defend with well founded arguments. If I turn down your arguments about cache management, and you claim: That's an insult, becase I knonw the microcode of the VAX 730" - well, then I accept that you are insultetd. It does not make me accept you as a guru on cache management.
If you feel that I have insulted you in a professional area where you indeed do have professional expertice, I beg you to rebut my argument on profesional grounds.
If you feel incompetent to do that, feel free to feel insulted.
|
|
|
|
|
Other than gaming laptops where with the biggest AAA games weighting in >100GB makes just a small SSD not a reasonable choice, and until recently the pricegap between a 240gb SSD and 1tb HDD and a 1tb SSD (good sata type) being rather large (currently with google top result prices it's about $50-75) I'm not really seeing split SSD/HDD storage anywhere and haven't for a while; and as small as the pricegap has gotten I'm half expecting that sort of split storage to disappear in next years mid/high end gaming refreshes. Other than as an option in configurators for semi-custom setups I haven't seen optane anywhere.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
matblue25 wrote: 4GB of DDR3-1333
There's your problem. Too much swapping.
What you maybe should have done is just upgrade the memory to 8 or 16GB -- it would probably have had the same effect on the speed of the device.
Also, if you're using virtual memory a lot, you'll wear out the SSD pretty quick, so upgrading the memory is recommended, anyway.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Probably not. Very few home PCs use 4 GB of RAM actively. Resource Monitor may indicate that you have > 4 GB "in use", but that covers all the data accessed by all the applications you have opened since bootup, and not closed again. And all the services that run once ever hour - or once every forthnight. If you give a command (or a service is woken up) that require a 5 ms disk access, that is a delay of 5 ms, nothing more.
Right now I have running a 4-tab firefoc, full Outlook, Lync, Docker, 123 services in "running" state (includeing Java, a Docker engine, Traps antivirus, remote login service, ...), 9 mounted network disks, Resource Monitor ... Still I am below 5 GB total RAM usage.
None of the processes are real memory hogs (with the possible exception of Firefox), none of them come even close to half gig of memory use, and out of that, three fourths have not been accessed for minutes. You very rarely have umpteen programs actually executing on your PC; they are waiting for some external event - timer, network input, or your interactive input. The waiting for an event doesn't go faster with more RAM, and you usually entertain only one program with your input at a time.
Looking at the page fault count might fool you: To make sort of an LRU memory handling, pages are taken out of the page tables long before removed from memory. When a page fault occurs, the memory handler will see that the disk is still in memory, and do not need to re-read it from disk. So "page fault" does not imply "disk access".
On most home PCs, making them really spend a lot of time on swapping (/paging) requires you to set up a rather artificial boquet of simultaneouly processing programs in a way that you never do in when routinely using the machine. You could then set up a test where the PC was chewing ahead with no interactive input to prove that going from 4 to 8, or from 8 to 16 GB RAM, in an extreme program mix could complete a huge task somewhat faster. But if it is non-interactive, who cares about a few seconds?
More RAM is a nice placebo, and it is "almost free" nowadays. So if you have a friend constantly complaining that his PC is slow because he has got only 4 GB, and you know that is not the real cause, then you tell him to buy more RAM just to stop his complaints. As a placebo. Besides, this is an excellent placebo so strong that it works even if you don't believe in it: You get rid of all your friend's complaining, even if you don't believe that more RAM has any affect at all.
Disclaimer: There are cases where computers are hogged down in paging/swapping - but that is plactically always in professional applications, not home PCs. Very few home PCs do FEM processing, weather forcasting or similar tasks.
|
|
|
|
|
I just bought a laptop couple of weeks ago but it'n not with SSD, i am planning to install my self one. Thanks for sharing it here, now i will surely install it in that machine. 
|
|
|
|
|
Noone talked about reliability. While I am OK for a SSD for the operating system, mechanical discs are still much more reliable than SSD. And we did not talk about size/price ratio. So I think RAID with mechanical still the way to go.
|
|
|
|
|
I have been working with computers long enough to have seen an long series of placebos - some placebos so strong that they work even for people who don'b believe in them.
An old one is from the 386 days, when you had to add an '87 chip (and have a motherboard prepared for it) for floating point hardware: I knew lots of people claiming that the speed of compilation increased significantly after plugging in an '87. A compiler most certainly does not make use of floating point instructions!
A more recent one is when people "speed up" their PC by adding another 8 GB to double the RAM size to 16 GB: When I hear this (from a home user - professional use is different), I ask to see the resource use in the Resource Monitor, often to see that less than one fourth of it is actually in use. (And you know that "in use" certainly is no "active working set" - a page that was last addressed ten minutes ago and would take five milliseconds to fetch anew, even on a magnetic disc, is still counted as "in use".)
Well, SSD is certainly not a pure placebo: It significantly speeds up the startup of programs, especially those initially loading a lot of resources from a multitude of files (but less so for programs loading resources "lazily", on demand). First time you open, say, one of the MS Office applications, after having installed an SSD, you are in your right to exclaim: Wow!
That's where the placebo comes in: Because it starts up so fast, you have a distinct feeling that all subsequent functions are much faster as well. 99% of that is pure psychological. What is needed in memory, is in memory. Maybe a couple disk pages are read now, a few then. Even if there is a physical access, maybe 5 ms is shortened down to less than 1 ms - but remember that all modern magnetic disks have ample sized RAM caches nowadays, so even a megabyte write doesn't have to wait for the rotation or disk arm. The cache is used for prefetching reads as well, and do it quite successfully with NTFS as long as your disk is reasonably defragmented: A large fraction of reads done after program startup are sequential reads of the next block in file - and the block is found in the disk cache.
Many high-data-volume applications are also real time in nature: Even though your video player spins through a few megabytes a second when playing a high-def movie, the movie won't play faster from an SSD - and any magnetic disk of this millenium has plenty of speed to keep up. Also, those making applications handling huge data volumes (such as non-linear video editors) have their roots in an age when double buffering were required, and previews in resoultion limited to the actual winwow size was mandatory - even on a 386 with disks from the 1990s, non-linear video editing went fairly smoothly. Those techniques are still in place, even though the "need" for them dissapeared at least ten years ago, long before SSDs.
SSDs give a true speedup of first-time reads of huge amounts of disk data, such as starting up an application of several multi-megabyte DLLs. Some software buffer a huge amount of file writing until you have finished your work and exit to do something else - you don't have to wait for the writes to complete.
Third: If you regularly copy multi-gigabyte files between disks - but then, both source and destination disks must be SSD and internal; otherwise the interface will be a limiting factor (most certainly so with USB 2.x, but it goes for USB 3 as well). How often do you move multi-gigabyte files between you internal disks? (Within the same physical disk, it isi just a directory update that goes in a snap.) How often you you copy them to an external USB 3 disk?
Yet, these are cases where SSB can show a significant speedup. But (the fast program startup in particular) those special cases make people "have a feeeling of" everything going a lot faster, when in fact it is totally unaffected by the switch to SSD.
|
|
|
|
|
Anything connected with file i/o will be faster. The act of loading an app, or a data file for an app, will benefit when it's on a SSD. How the apps process after that will not benefit from a SSD UNLESS the system doesn't have a lot of RAM. At that point, disk paging will benefit (as long as the paging destination disk is also a SSD).
For raw speed, you want a PCIe nVME drive. It's alll about the width of the bus (and a PCIe nVME drive will always be faster than a SATA SSD).
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: Anything connected with file i/o will be faster.
Not unconditionally. If your rotating disk has a 64 MB RAM buffer (which is not uncommon today), you can write several MB to the disk without waiting for the physical disk access to complete. For piecewise, but sequential, read of a file, either the disk itself or the OS may read a much larger chunk of data - typically: a physical disk track, or an entire NTFS extent (up to a certain maximum) - into a cache, so that your next 'n' I/O-operations do not access the disk at all.
From interactive user perspective: More advanced applications do disk I/O in a background thread. Especially for writes, the user need not know when the operation is complete, need not wait, but continue with his next operation. CPU bound systems using double buffering need not be delayed by I/O at all: If processing a disk page requires 10 ms, and the next page is fetched in parallel, it makes no difference if the fetch completes in 5 ms or 500 uS, when there still is either 5 or 9,5 ms of processing left for the previous page. The total time limited by CPU (or GPU or communication line speed or ...), not by disk I/O.
It would be more correct to say that any operation that is disk I/O bound, and leads to a physical access to the disk (that is, depending on arm position and rotation - not access to the disk's RAM buffer), will be speeded up. But those situations are really few and far between, except at startup of a program that insists on loading several huge DLLs and accessing them all over before giving control to the user.
Even for program startup: Remember that an .exe or .dll is accessed as a memory mapped file: The page table entries are set up to point to the file pages, but the pages are not read into (main) RAM until actually accessed. If the .exe or .dlls are so huge that setting up the page tables takes a whole lot of time, there is very little difference between SSD and magnetic disks, especially on a reasonably defragmented NTFS file system.
I have been working on systems where the code designers were very careful to gather everything required for startup and initialization in as few disk pages as possible, to minimze paging before the user got control. A fairly cheap way to increase user satifaction
|
|
|
|
|
This all works wonderful as long as you don't get into the UEFI vs. legacy boot wars. I'm not even sure one can blame this on Microsoft, but following it's tradition, Microsoft's support web site is full of useless gibberish from support people. I really think it's an early Microsoft AI engine posting solutions....
In any event, if you clone your spinner to an SSD, the SSD might not boot, actually displaying an assortment of exception conditions.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Haven’t had that problem, yet.
|
|
|
|
|
Completely unexpected on my part, had to go off on a research project - wtf is UEFI (or whatever). All sorts of contradictory answers, and of course, Microsoft folks chime in with "you'll just need to re-install Windows". Uh not happening....
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
This might help. UEFI can boot from either MBR or GPT partitions but BIOS can only do MBR (I think).
UEFI and partition types
|
|
|
|
|
When I swapped to an M.2 SSD, I installed W10 over the course of a commercial break.
3 minutes from cold boot to interactive use on a new install; SATA-based can't even come close to that.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Linux is even faster. I have a full ubuntu install on a laptop with a nVME drive, and from power-on to login prompt, it boots in about 30 seconds (even faster if the USB drive is plugged in, because grub insists on looking for it for at least 10 seconds before it times out and continues the boot process.
On another machine, I'm running a minimal Lubuntu (also on a nVME) - less than 10 seconds on that one.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You misunderstand. I installed windows in that time frame.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
I agree. I have an m.2, 4x pcie SSD and it benchmarks three times faster than a SATA SSD on the same computer.
|
|
|
|
|
Scary how dang fast the pcie drives are...
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
