I'm trying to use emeditor to delete duplicates in a 13gb file. 1 column, just newlines of text.
However, both tools to do this in emeditor (under edit->advanced) give me the same error of "Not enough memory resources are available".
Is there another way to do this? Any alternatives? Thanks
If not using a language
I would use Notepad++ and a simple
Find (?m)^(?>(.*?\S.*)\R)(?=(?:.*\R)*?\1$)
Replace nothing
demo
Removes dups from top down, its the fastest regex way to do it.
This prompt message means that available virtual memory is very low on your computer. How much physical memory do you have on your computer? I would recommend you to increase the physical memory size in your computer if possible. If that is not possible, please try:
Clean up your computer, and make sure you have enough space available in your hard drive where temporary files reside. The temporary folder can be set in the Advanced page of the Customize dialog box.
Close all apps, disable Cortana if not used, disable any startup apps if not used, restart Windows, and run only EmEditor.
Go to Customize on the Tools menu, select Advanced, select 1 from the Number of Threads.
If the prompt message still persists, you might need to check your Windows virtual memory settings. To check virtual memory settings, search for performance in the Windows Settings search box, select Adjust the appearance and performance of Windows, click the Advanced tab, click the Change button in the Virtual memory box.
If the Automatically manage paging file size for all drives was not set, try setting this automatic option first, restart Windows, and try again.
If this doesn't work or if the automatic option was already set, then clear the automatic option, try settings the Custom Size of 40960 MB for both Initial size and Maximum size, restart Windows and try again. I hope this works.
Related
We just virtualized a Windows server in Azure and everything in working fine on Client side, but we are not being able to solve the indexing search problem.
When you have a local drive, Windows can index the path and searches works fine using Windows menu/search box in task bar. But for shared drives it seems to fail.
In Windows Explorer the search pretends to work, but it takes forever to find a file or folder. And sometimes it just won't move anywhere. So it is not an option for users since them are used to search using menu bar.
We have tried to change drive properties in Right button to Shared Driver > "Allow files on this drive to have contents indexed in addition to file properties, but it was already enabled.
When we try to disable it, it prompts an error saying that the user doesn't have permission to do it, but it does anyway. And when we try to re-enable, the message prompts again, but it is enabled with no problem at all. But once again, nothing changes and Initial Menu Search just won't work.
Does anyone knows if there is a solution for that?
For me it seems to be an server setup since I see that permission error, but, as far as I know, if the shared driver is already mounted, I can't see a reason why Windows can't index it.
Ps.1: In the shared drive security tab, the System has full permissions.
Ps.2: If there is a solution for this, is that possible to solve it on the Windows server Side so we won't need to access client by client to change it manually?
enter image description here
Please check the following setting and see.
1.First thing is to check network location is being indexed. open File Explorer right-click on the mapped network drive that you need to index, then select the Properties and Make sure that, the Allow Files on this Drive to Have Contents Indexed checkbox is selected.
You have already done this step
2.try to check the search options for network drive in file explorer, go to view tab>>click on Options Icon and choose the change folder and search option menu it will open the folder options dialog box and select search tab and make sure first option is not selected
3.check server side Indexing
4.we need to make sure search service needs to be running.
Open services.msc check for the wndows search service and try to restart the service.
5.Go to Settings on the Windows 10 desktop, then click on Search, followed by Searching Windows scroll down and try to run the indexer troubleshooter
Reference https://learn.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/fix-problems-in-windows-search
In my Electron app, I am trying to use dialog.showOpenDialog() to allow users to choose the image file that they want to open. On Ubuntu 18.04, when they choose an image file, a preview of the image would appear on the right side like so:
https://i.stack.imgur.com/RG6Po.png
However, if the user chooses a file that is too large (typically 1GB+), my app would crashes, with the following being printed on the command line:
tcmalloc: large alloc 1073741824 bytes == 0x32f584ab4000 # 0x7fb5985b16cf
I tried disable thumbnail generation in the Search & Preview tab of the file manager but it didn't disable this right-hand-side preview in the dialog box.
My app works with very large raster files so being able to choose these image files is crucial. I have considered either installing a new file manager or moving my code to another OS, but I want to ask beforehand if there is any less drastic solution that I can take?
The previews are being added to the GtkFileChooserDialog by Electron itself, so changing your file manager or its settings won't have an effect. Changing OS would work, of course, as drastic as it is.
It does seem like Electron should offer an option for turning off previews among the platform-specific ones in dialog.showOpenDialog. At the minimum, it should enforce a reasonable cutoff on file sizes for previews.
To accomplish that, you'd have to patch Electron locally (and then ideally submit a PR). Whatever you decide to do, I don't see a bug reported about this in the Electron repo, so doing that could be helpful to anyone else who runs into the problem.
I am trying to write a program in which when you can open up the PerfMon and it will already have a certain set of counters displaying. This set of counters can be specified by the user. I really thought this would not be an uncommon thing but I have not found anybody talking about this online.
My question is how can I tell the PerfMon which counters to show when it starts up? I considered creating my own .PerfmonCfg file but it is a binary file and I could not find any documentation on the layout of the file (didn't really expect to, either.)
*Alternatively, is there a way to add in the PerfMon into my program (.NET framework program)?
Thanks in advance!
Yes, there's an ActiveX control available for this. Right-click the Winforms toolbar, Choose Items, COM tab, tick the "System Monitor Control" item. Drag it onto your form and set its properties. The normal context menu is available as well.
The programming guide is here.
You can also do this by opening an MMC (start-->mmc.exe) and then adding a Perfmon instance to the MMC. Add whatever perfmon counters you want. You can then save the entire mmc to the desktop with a name based on your counters, like "processor utilization." Close the mmc, reboot the computer, etc. The next time you open the mmc, it will display the counters you originally added to the console.
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...
One of my programs seems to be changing the Display Properties > Appearance > Effects > Show window contents while dragging setting to off every few hours.
I'm not sure exactly which program, or when it happens. I have a number of programs that seem like likely culprits - wallpaper rotators, software for multiple monitors, multiple virual desktops and switching, and a few others.
I am just thinking to create a little batch script to run periodically and set the setting back to on.
Does anyone know how to do this in windows? I'm using xp pro sp3.
Thanks!
The best option is to do this programmatically using the supported API. i haven't tested this, but it should do the trick:
SystemParametersInfo(SPI_SETDRAGFULLWINDOWS,
TRUE,
NULL,
SPIF_UPDATEINIFILE | SPIF_SENDCHANGE)
You can use SPI_GETDRAGFULLWINDOWS to see if the the bit has been flipped to avoid unnecessarily triggering a WM_SETTINGCHANGE.
You can use RegMon to find the program that keeps changing your settings. Maybe that's a better start than hacking around it.
There is a simple and effective solution to this problem. In Notepad type the following lines :
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop] "DragFullWindows"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects\DragFullWindows] "CheckedValue"=dword:00000001 "UncheckedValue"=dword:00000001
Save the file as "Show Window Contents.reg" Double clicking this file and restarting will cure the problem permanently. Post a message if you find this useful.
Aravind Banerjee
It seems the registry setting which controls that preference is HKCU\Control Panel\Desktop\DragFullWindows. You can read more about it here. However, trying it on my own computer does not register the change right away, so a batch script won't do it. You'll probably have to write a program to manipulate it using SystemParametersInfo(). You can pass it the SPI_SETDRAGFULLWINDOWS parameter. Here's a page explaining it more. Here's a page showing how to call it, albeit not for the same parameter.
I suspect it's kept in the registry - maybe [HKEY_CURRENT_USER\Control Panel\Desktop] - "DragFullWindows"?
It would be easy to flip the registry setting back to "1" every hour or so with a batch file.