Hacker News Reader

Comment by gigaflop | Hacker News Reader

This reminds me of Windows Search Indexer on my PC. Microsoft's spying aside, it apparently needs 13.5% or more of my CPU at all times. It started after I updated multiple time sin a row, and for the past few weeks, has never stopped. I've killed it via task manager, only to have it come back shortly after.

View on HN

One of my first tasks after a clean install of Windows is to disable any unnecessary services, including the Search Indexer. Not only do I disable the service itself, but I also explicitly remove all folders from the "indexed locations" control panel, and explicitly disable the "Allow files to be indexed" bit on the disk itself.

I've literally never needed to search my disk for a file (using the Windows search interface), and if I ever do, I'd rather wait a few more seconds that one time for my search to complete, rather than have the indexer consume my CPU at all times.

My PC had been fine before the updates (hence not updating until I needed some other thing to work), and I'd never seen Search Indexer pop up in Task Manager in any notable way. something tells me that I might just have a broken version of it, and since Windows Update also looks to be a bit broken, I may just be SOL for the near future.

This set of problems may be obviated by actually getting Manjaro to cooperate. It's on the todo list.

Try out Fedora! There's Fedora Rawhide if you want rolling release.

I have been using Rawhide (+ mainline, non rc or git, kernel) on my work machine for the past 6 months without issue.

If you have to compile a lot of kmods it can be a pain as everything is transitioning to GCC12 but the kernels are still built with GCC11. A container can take care of that though.

I really want to like Fedora - it gets so much right. But: `yum` is the worst package manager I have ever used on linux by far, and that sours the whole experience. I wish I could get "Fedora with pacman/apt instead".

Hm, maybe try using Nix alongside it?

dnf replaced yum I believe. dnf is certainly much nicer than pacman, it's slower but does a lot more to ensure your system actually works.

dnf is what replaced yum, and it's alright.

yum is still aliased on most fedora / rhel systems so you can put Fedora 35 on a drive and run yum update -y and it'll kick off the associated dnf process.

Why is it the worst package manager?

I haven't used it since ~2005, but at that time it was inexcusably slow. Notably, remarkably, shockingly slow. I would dread invoking it, it was so slow. 10x the time to do many operations, as apt/dpkg, and that's not an exaggeration.

I assume that got better, though. I hope it did.

That "yum" no longer exists. dnf has a "yum" alias so that scripts still work, and a lot of the commands are named the same and accept the same arguments, but that's basically where the similarity ends.

And yes DNF is much faster.

Fedora hasn't used "yum" in 7 years (although the alias still exists). I'm curious whether you've ever actually used Fedora.

It would be acceptable if windows search worked well and was fast -- but it's not. I search for something and it still churns the file system looking for my search query. What is the point of all that indexing if it still seems to always traverse the fs for each search!? By comparison, a third party search application [1] gives me results as soon as my key lifts and doesn't excessively index (at least for me). [1] https://www.voidtools.com/

A reindex of my entire drive in Voidtools Everything is substantially faster than a search in Windows Explorer over that drive.

That does speak to the remarkable efficiency of Voidtools Everything, as I understand it they don't use Window's filesystem stack but parse the NTFS partition directly. And I get that the Windows indexer is technically more powerful because it indexes file metadata like author etc. I still don't get what makes Windows search this slow.

If you use Windows as a daily driver, Voidtools' Everything should be in your top 10 first apps to install (or in your install script...). I have been using it for the better part of a decade, no issues, no resource consumption, just lightning fast searching for files of all drives on your system.

You need to go in the Search Indexing setting to remove the directory for indexing. And only tick the directory that you want to index.

Also to completely disable it, you needs to disable the service and remove the entry from schedule tasks. It keep coming back because of the service and scheduled tasks are not disabled. This is how Google Chrome keep starting up their updater and bypassing my disabled startup entries for Chrome. Because of scheduled tasks is not removed, Chrome uses that to reactivate their updater and recreate a startup entry. Managed to completely neutered Chrome updater through Sysinternals AutoRuns.

Windows Search Indexer and Windows Update are probably the worst two components in Windows, though at least Windows Update has gotten noticeably better in the last few years.

Even worse is the Mac search indexer. Ever wonder why your CPU temps are pinned at 90c in low-power mode? Open activity monitor, cmd+f for mdworker, and you found your culprit. It's insane that they enable thay be default...

I've never had spotlight hog things for more than a few hours, and only after a fresh install. It's generally well behaved. And it's very useful and fast for searching.

A few hours is a pretty long time for a CPU to be running at near-T-Junction temps. On top of that, every time I pull from a larger repo or unzip a large folder, MacOS will decide it's time for me to take a quick 2 hour break while it depletes 60% of it's battery. Instead of setting up a complicated ignorelist, I just disabled Spotlight indexing altogether.

I do wish it was faster. I will say, however, that I never really noticed it on my new M1 macbook. They made it less intrusive, I guess. It used to be quite bad for a few hours and I'd sometimes just walk away and grab lunch, or time my new system install for bedtime. Perhaps the switch to SSDs helps as well, it's easy to forget how slow laptop spinning rust was.

If the content of the folder or repo have thousand of files and folders, then it would made sense for Spotlight to index them all.

It the same for transferring the folder/files to other location. a single 1GB file will take 5 second to transfer to external hard drive. A 1GB non-zipped folder (consists of thousands of thousand file from 1KB to 1MB each) will take half hour or more to transfer to external drive. I have a 150GB folder that contains over 500k of files, averaging 120KB to 4 MB, will take 3 hours to transfer to the external drive. I have another 120GB folder that are consist of videos, averaging 300MB to 10GB, took 20 minutes to completely transfer to external drive. This transfer through NVMe ---> spinning rust external drive through USB 3.1.

If you are pulling a large repo that have thousands of files in it will take a while for Spotlight to index each file. That is not the fault of Spotlight, that is just the way it is because it have to scan individually each file to index.

Reply on news.ycombinator.com