UltraEdit is getting very slow on startup

foresthus · Mar 20, 2006#12006-03-20T18:28+00:00

Hi,

first of all I want to thank Ian for this TOP product.

I'm using UltraEdit since version 4.xx and am still using this very cool program, but since version 12 it is getting slower when it starts.

Is there a new code or why is the starting more slowly? :?: :?:

Mofi · Mar 20, 2006#22006-03-20T18:58+00:00

I can't see a significant difference of starting speed between v11.20b and v12.00. Which version do you have used before?

Also search with the forum search engine for word speed. You will find some topics about which settings can cause slow startup of UltraEdit.

daviescj · Jul 04, 2006#32006-07-04T02:50+00:00

I have the same problem with version 12. It takes, on average, 60-70 seconds for UltraEdit to open fully. It's so bad that I use it only when I have to, which is sad, since I have been using it for many years.

If UE is doing some non-essential scanning (e.g. Registry) or loading of files during startup, then it should have some switch that allows the user to disable or defer it.

Mofi · Jul 04, 2006#42006-07-04T10:50+00:00

60-70 seconds? Something is wrong on your computer. UltraEdit v12 must start within 2 seconds depending on your computers performance (CPU, RAM, hard disk, ...). Use free Sysinternals Process Monitor to find out what is causing this extremely long load time.

Please turn off at Advanced - Settings or Configuration - Editor - Advanced the option Load/restore printer settings if your default printer is a network printer which is not always accessible, or a local printer not being turned on all the time when your computer is running. See help of UE about this setting for details.

hveld · Jul 04, 2006#52006-07-04T17:01+00:00

I had a similar problem after upgrading a perfectly working UltraEdit v12.00 to v12.10a.
UE became slow and started to crash very frequently. So I backed up and deleted all the configuration files in %APPDATA%\IDMComp\UltraEdit\.
Then manually copy/pasted some parts of the old uedit32.ini to the new one (mainly tools), then configured the rest from the GUI - now it's working fine again.
There is maybe some problem with the old settings and v12.10a, although I haven't compared the configuration files and have no idea what it may be.

NOWUX · Jul 18, 2006#62006-07-18T16:06+00:00

I had the same problem and solved it in the same manner as hveld has described earlier.
I just deleted all FTP related entries from uedit32.ini because I remembered that UE slowed down after I had created an FTP account. Deleting that FTP account did not help but deleting all FTP related entries from uedit32.ini was the solution for me.

Hope this helps.

dkellner · Jun 29, 2013#72013-06-29T18:26+00:00

May sound strange but I've found that the SEARCH DIALOG can slow down UltraEdit dramatically, even when you're not doing a search. It just depends on what you've left in the dialog - there are (seemingly random) phrases containing slashes/backslashes that do this. It's silly; like you have searched for "yadayada" and suddenly you notice that the UE window itself won't redraw properly (it takes 4-5 sec!), then you go and delete the search phrase and bingo! you're lightning fast again.

It may sound strange. It is strange. In my case "\/\/cue: - .*$" was the search phrase, without the quotes - and of course it's a regular expression - but I guess it can be a couple of things. Again, I was not running the search when this thing happened; merely having it in the box causes the strange effect, even if you exit UE and start it again.

The last time I've checked this was april 2012.
Hope this helps.

Mofi · Jun 29, 2013#82013-06-29T20:31+00:00

I have run a Perl regular expression search with the string \/\/cue: - .*$ and now with this search string in Find list in the toolbar there is no slow down.

Maybe it helps to use from time to time the button Clear History at Advanced - Configuration - Toolbars / Menus - Miscellaneous to clear all history lists and therefore reduce the number of find/replace strings from 250 each to 0.

By the way: The forward slash / has no special meaning in any regular expression syntax and therefore does not need to be escaped at all with backslash.

dkellner · Jul 01, 2013#92013-07-01T10:33+00:00

Thank you for trying it - well, I don't know what phrase can cause such a thing and how to reproduce the error but one thing is sure: it was not the sort of slowing down for having too much items in a list. What I've seen (and panicked about having to reinstall, etc) was real and low-level, that is, for example when I switched to another task and back, the window redrawing stopped at a very early state like displaying the UE logo on the top left and HALF of the window, then freezing for a while (as much as 5-15 seconds) and then showing the whole thing. I am a programmer myself but I have NO idea how to achieve the same effect in a win32 app.

This is an ugly, irreproducible bug that you might have fixed already without actually knowing it.
So, my reply was just one more guess for the poor fella trying to fight this slowdown.

Mofi · Jul 02, 2013#102013-07-02T06:12+00:00

dkellner wrote:This is an ugly, irreproducible bug that you might have fixed already without actually knowing it.

I'm not an employee of IDM, I'm just a user like you. I don't know if the IDM developer has improved something here.

My experiences with windows not refreshing quickly or being drawn very slow are caused by:

An application or a driver process is running in a higher task priority than normal and the CPU is a single core CPU; for example my company configured McAfee updates being processed with a priority higher than normal which is no problem on a multi-core CPU, but on a CPU with a single core this results in no response of all running applications while the McAfee update in background is in process. I detected this reason using Sysinternals Process Explorer as this tool displays also the process priority.
Windows is running out of memory and therefore swaps memory to virtual memory on hard disk (pagefile.sys) indicated by a heavy blinking hard disk activity LED. Please note that even with 4, 8 or 16 GB RAM on x64 machines an out of memory situation can occur easily if all 32-bit processes reach in total its 2 GB limit. Only 64-bit processes can make use of more RAM at all.

It is nevertheless possible that there is an issue within UltraEdit causing the slower display update and if you find it ever out in a reproducible way, please let IDM know about this issue by email to support. I can only add that I have never seen a display delay caused by search history entries in the last 15 years using UltraEdit, but I have configured UltraEdit to record as less as possible in uedit32.ini and I'm clearing the other histories quite often.

dkellner · Aug 01, 2013#112013-08-01T22:01+00:00

Mofi wrote:My experiences with windows not refreshing quickly or being drawn very slow are caused by:

An application or a driver process is running in a higher task priority .....

Windows is running out of memory and therefore swaps memory to virtual memory .....

That's clear and thank you for the list - but no, what I'm talking about is (was) specific to UE and believe me, I have not the slightest idea of what it could be. Of course I know trivial things and I went after this bug quite a bit, including task manager performance monitoring and killing processes one by one - but then it was very clear and very easy to see that the problem was UE itself. Just took me a while to believe it. Then it also took me a while to figure out (no, randomly pop into) what caused the problem.

It's silly, it sounds like it makes no sense. Yeah. I know. But there it was, my search string, and I removed it and the problem was gone. Then I put it back again and the problem appeared again. So you can imagine how surprised I was. And I knew it was something like seeing a UFO, knowing exactly what everyone will say + think

Okay, just wanted to share that.

Mofi · Aug 02, 2013#122013-08-02T05:25+00:00

So if indeed a search string is causing the slow down, please send IDM support by email your uedit32.ini containing the search string as ZIP file and explain how to verify that this search string is the problem. Hopefully, IDM support can reproduce the issue with your configuration file and your information and the developers of IDM can next find out the problem and fix it.

fleggy · Dec 17, 2013#132013-12-17T17:39+00:00

Hello,

I had exactly the same problem - a search pattern starting with // caused the slow start (analyzed with Process Monitor). I reported this issue and UE was fixed but I don't remember the fixed version number. However the versions 19 and 20 are OK.

Mofi · Dec 18, 2013#142013-12-18T12:41+00:00

I reported in July 2011 that UltraEdit searches on startup in active working directory several times for a file with name being equal last search string as I could see on a log created with Process Monitor on searching for another issue on startup. This was definitely a bug as the last search string should not be interpreted ever as name of a file to reload. I forgot those report, sorry dkellner.

As I'm currently evaluating which reported UltraEdit issues were fixed in the meantime by IDM, I detected 4 days ago that this bug was fixed with first released version of UE v19.00. This bug was fixed with UE v19.00.0.1022 as can be proved by me. UE v17.xx and v18.xx have definitely the bug searching in active directory on startup for a file with name being equal last search string as shown in search box in the toolbar. I don't know in which version of UltraEdit this bug occurred the first time, but could find it out if somebody is interested in.

I suggest to clear the histories with button Clear history at Advanced - Configuration - Toolbars / Menus - Miscellaneous for the versions of UltraEdit effected by this bug when startup of UltraEdit takes longer than usual.

Otomatic · Apr 22, 2014#152014-04-22T15:52+00:00

Hi,

I apologize for my bad English. (It is said that the French are not good at foreign languages)

I waited a long time to put my message about this, but it seems to me that the load times have increased dramatically since the upgrade to version 20. For several years, my "projects" are substantially the same, so I can see this increase loading time.
Motherboard ASUS P8Z77-V - Processor Intel Core I7-3770K (3.6 GHz) with eight cores - 16 GB memory
Windows 7 Pro 64 bit - UltraEdit 21.10.0.1026

- Loading of UltraEdit (Without files): 2 sec
- Loading a project of 10 files (about 30 KB each): 3 sec
- Loading a project of 23 files: 16 sec, with (Does not respond) in the title bar
- Loading a project of 84 files: 25 sec, with (Does not respond) in the title bar
Note: The setting Load/Restore printer settings is unchecked.

I am open to any suggestions that would allow me to see where could locate the bottleneck.

Best regards.