Yes, yes, running Everything with default settings is not a problem (two other instances work well), but the settings I set in "Content" and / or "Properties" are, I guess. Too much information to keep having in the RAM for Everything, I assume. So I guess, I have to deactivate the less useful properties (without to losing too much data, indexes, etc.). But when I start Everything (after having deactivated the "Content" indexing) Everything (and other programs) still crashes. Maybe it still uses so much RAM to process the new information and after processing the RAM use would be OK.Check if a setting it's the problem.
Sorry, what files? The indexed ones? About 6.7 mio. files and folders. Each file / folder I have is indexed.About how many files were we talking?
content: addcol:a a:=LEN($content:) sort:a-descendingBesides of the two lines, I guess. And what does it mean here? Is it good or bad? Is it like it should be? So Everything obviously wrote the new ini file.The ini files are the same.
Most of them I use quite often, I think.Are you using these indexes?
What exactly is the difference / speed between the fast sort and the usual sort (so without activated fast sort)? Sorting lasts (much) longer only?its the fast sort that will use the most RAM here.
Yes, indeed, that actual was the problem here. Content indexing uses extremely much RAM as I could see. But I do not anymore. I had deactivated the context search but Everything (and other programs) crashed all the time after that (too less RAM messages or so). Suddenly Everything did not crash anymore and now the RAM use is between 250 MB and 1500 MB. Before it was up to 11000 MB or more. So I guess up to 1500 MB is the size Everything uses now with all the other settings kept activated. And that seems to be the amount of RAM use you added above with all those properties activated?Content indexing may consume large amounts of RAM.
I don't recommend indexing over 1GB of text content.
Looks like a search for the content (not being indexed anymore). So I assume it would not find anything anymore? I tried that search, but I had to stop it because it uses to much RAM (up to 95 GB or so). Because of the crashes. I could do at a later time.Please try the following search:
content: addcol:a a:=LEN($content:) sort:a-descending
No, not that I can find one in the context indexed folders.-Maybe you are indexing a log file?
-Maybe Everything is reading a binary file as text?
I would estimate about 1500 files had been content indexed. And some or many over 1 MB.Reduce the number of files you are content indexing with content indexing filters under Tools -> Options -> Content.
It's fine.Besides of the two lines, I guess. And what does it mean here? Is it good or bad? Is it like it should be? So Everything obviously wrote the new ini file.The ini files are the same.
Sorting by the associated property will be instant when fast sort is enabled.What exactly is the difference / speed between the fast sort and the usual sort (so without activated fast sort)? Sorting lasts (much) longer only?its the fast sort that will use the most RAM here.
1500MB is expected for your setup.Yes, indeed, that actual was the problem here. Content indexing uses extremely much RAM as I could see. But I do not anymore. I had deactivated the context search but Everything (and other programs) crashed all the time after that (too less RAM messages or so). Suddenly Everything did not crash anymore and now the RAM use is between 250 MB and 1500 MB. Before it was up to 11000 MB or more. So I guess up to 1500 MB is the size Everything uses now with all the other settings kept activated. And that seems to be the amount of RAM use you added above with all those properties activated?Content indexing may consume large amounts of RAM.
I don't recommend indexing over 1GB of text content.
This search will only work when content indexing is enabled.Looks like a search for the content (not being indexed anymore). So I assume it would not find anything anymore? I tried that search, but I had to stop it because it uses to much RAM (up to 95 GB or so). Because of the crashes. I could do at a later time.Please try the following search:
content: addcol:a a:=LEN($content:) sort:a-descending
I would recommend indexing only a specific folder and subfolders, eg: C:\users\your-username\documentsI had intended to context index every text file (doc, docx, odt, pdf, etc.), html, htm file, etc. on the next computer with 64 GB or 32 GB RAM, but it seems that abosultely is not a very good idea. I assume, it is not possible at all (with 6.7 mio. items)?Reduce the number of files you are content indexing with content indexing filters under Tools -> Options -> Content.
I would estimate about 1500 files had been content indexed. And some or many over 1 MB.
Yes, it must be the old one I sent you. Actually I woul think the crashes are caused by the shitty Lenovo. Usually it should not happen that the computer crashes because of too less RAM.Did you have a copy of the old ini that was causing crashes?
Oops, one or two?! I had thought it might take minutes or so. So I am wondering if it is worth 624 MB of RAM. I should try it. But once deactivated it would take some time after re-activating it to re-index the information needed?Sorting by the associated property will be instant when fast sort is enabled.
Sorting without fast sort can take a second or two.
So upt to 1717 MB? Why is it that Everything uses so different amounts of RAM, 300 MB up to 1500, 1700 MB?1500MB is expected for your setup.
My RAM usage guess using the numbers from above:
670MB + 500MB - 192MB (size and date modified included in 670MB) + 739MB
=1717MB
Sorry, what is indexed content instance? I use two normal instances. Is there a way to index content without using so much RAM?Consider creating a separate indexed content instance.
Ah, OK, I should have used earlier.It would help to identify any problem files that might be consuming larges amounts of RAM.
Yes, but that meant one had to separate them from the folders they belong to.I would recommend indexing only a specific folder and subfolders
One could not just exclude them?This is going to index log files.
Oops, why? An extern WD MyBook or WD Elements is slow?Only index content if the files are on a slow HDD.
Why?There's very little reason to index content on an SSD.
Yes, HDD it's slow.Oops, why? An extern WD MyBook or WD Elements is slow?
Because you can obtain the content information directly by searching.There's very little reason to index content on an SSD.
Why?
Everything will perform a quick reindex when toggling fast sorts.I should try it. But once deactivated it would take some time after re-activating it to re-index the information needed?Sorting without fast sort can take a second or two.
1717MB is my guess for the RAM usage based on your settings.So upt to 1717 MB? Why is it that Everything uses so different amounts of RAM, 300 MB up to 1500, 1700 MB?
A separate instance just for content indexing.Sorry, what is indexed content instance? I use two normal instances.
No.Is there a way to index content without using so much RAM?
I do not recommend indexing all txt and html files.One could not just exclude them?This is going to index log files.
Only consider indexing content for HDDs.Oops, why? An extern WD MyBook or WD Elements is slow?Only index content if the files are on a slow HDD.
Consider content indexing to search offline content.So a normal content search (without index) on an SSD with a normal program is as fast as Everything on a (indexed) HDD. But I would think, if one wanted the content being searchable offline content indexing would be useful, or I am I missing anything? How would one search content with Everything on an online SSD without content index?
Ah, so I could just activate / deactivate it when I need it / not need it (without long hesitations für re-indexing). That's great!Everything will perform a quick reindex when toggling fast sorts.
Everything will re-use your existing property index, it will not regather properties from disk.
Somehow I assume, that's not what you want, sorry, but I cannot find more processes:Please show all your Everything processes (sort by name) with the Commit size column shown.
Much too slow?If it's less than the working set size it usually means Everything has been paged to disk (bad)
The trashy Lenovo IdeaPad 3 has 16 GB RAM, 2 of them reserved for something, forgotten for what for. So 14 GB that are usable for the programs, I guess.-How much RAM does your system have?
Ah, so a normal instance. Not a special one for content indexing, okey.A separate instance just for content indexing.
But what would be the advantage? It would cost more RAM, wouldn't it? And the amount of RAM need would be the same as using the main instance, I would think.Using a separate instance might make it easier to manage your content indexing.
But that is exactly one of the best / most important options of Everything. So I thought it indeed is designed for it.However, Everything is not really designed for offline files.
Zugesicherte Größe is the commit size.Somehow I assume, that's not what you want, sorry, but I cannot find more processes:
Ideally, you would only run the indexed content instance when needed.But what would be the advantage? It would cost more RAM, wouldn't it? And the amount of RAM need would be the same as using the main instance, I would think.Using a separate instance might make it easier to manage your content indexing.
Yes, it sometimes greys out, gets inaccessible. But the search generally works very well.Everything will run very poorly.
OK, thank you!I recommend unchecking ALL options under Tools -> Options -> Indexes, and checking only the following:
Enable Journal.
Index file size.
Index folder size.
Fast size sort.
Index date modified.
Fast date modified sort.
I recommend unchecking ALL fast sort options under Tools -> Options -> Properties.
Not possible on the poor Lenovo. How much RAM should I have for Everything (for the next computer)?Install more RAM.
OK, thank you very much!Consider forcing Everything to keep memory in physical RAM: (not recommended)
In Everything 1.5, from the Tools menu, click Options.
Click the Advanced tab on the left.
To the right of Show settings containing, search for:
virtual
Select: virtual_lock
Set the value to: true
To the right of Show settings containing, search for:
working
Select: min_working_set_size
Set the value to: 2147483647
Select: max_working_set_size
Set the value to: 2147483647
Click OK.
Enabling these options can cause poor system performance.
virtual_lock
min_working_set_size
max_working_set_size
Yes, but the risk of crashing programs / freezing system, etc. keeps staying.So rather than Everything using 10000MB of RAM all the time, you only run it when needed.
But even with 64 GB RAM one had to carefully chose what files to content index, I assume. So even with about ten times (maybe 15.000) the amount of files I had have content indexed would use the 64 GB to capacity, I could imagine.In short, do not use content indexing unless you have plenty of RAM.
Really depends on your usage of Everything and other programs.How much RAM should I have for Everything (for the next computer)?
OK, and even that is not that much content, I assume. Maybe it would be good to save html files. as PDF. That would leave out the code and maybe other useless information not saved to PDF.For example, if you want to index everything where Everything uses 16GB of RAM, then make sure your system has 4x 16GB (64GB RAM)
Ah, I had missed that completely. I do not understand what "si" means. And this: " Search for files or folders in the system index that match the specified system index search." What are the advantages of that? What is it good for? What is "system index"?Consider using the system to index content and search your system index from Everything with si:
Optimal settings for Everything
si: == system indexI do not understand what "si" means.
Your windows index or windows search.And this: " Search for files or folders in the system index that match the specified system index search." What are the advantages of that? What is it good for? What is "system index"?
Of course you can search content without content indexing, just use the content: search function.Could one search context with Everything without having context indexed?
So the common Windows search. OK.Your windows index or windows search.
Same results as you would see in Windows Explorer.
No, I never have used it.Have you disabled Windows Search?
si:Indexing OptionsYes, it finds 1090 items of 376.000 on C:oes a search for
si:
find any results.
OK, thank you. But I am afraid that Windows might scan files time using CPU, RAM all the time. Does si: (and system-index:) after Win has completely indexed the drives find files instantly? Or what is the difference between using content:? The advantage of using the Win search or index with Everything? Does Win index content at all?To add a folder to your Windows Index:
From the Start menu, search for:
Indexing Options
Click Indexing Options.
In Indexing Options, click Modify.
Check the desired location and click OK.
Wait for Windows to index your newly added folder.
Hi Void; I think that I understand all this now.void wrote: Fri Jun 27, 2025 1:10 am .... You are indexing every basic property under Tools -> Options -> Indexes.
.... I see you are indexing several properties.
.... I see you are indexing content.
.... Content indexing may consume large amounts of RAM.
.... I don't recommend indexing over 1GB of text content.
Yes, Instantly.Does si: (and system-index:) after Win has completely indexed the drives find files instantly?
The Windows index stores the content in one location so it will be quicker.Or what is the difference between using content:?
Windows index stores the content on disk.The advantage of using the Win search or index with Everything?
Yes, content and properties.Does Win index content at all?
Just keep in mind I am referring to the "text" content part.Hi Void; I think that I understand all this now.I don't recommend indexing over 1GB of text content.
Yes, no worries about what files to scan and / or where to store them. Sounds good actually, I will try. One drawback will be that one could not transfer the Win index to another installation of Win. So one had to scan the entire drives again.In your case, the Windows index is best for content indexing.