If you haven't already, you might want to send this information to IDM support and see if they have anything to say. It seems they might have a decent chance of knowing (or finding out) what's going on between those two events.
Hello,
Wondered what happen to the fast and light editor I used to like.
I've been using UltraEdit for years and I can't really put my finger on the exact version but I feel that the editor is getting heavy and loading speed becomes slower with time.
Just got a new Lenovo Yoga 900 laptop with Windows 10 , loading takes sometime 5 or 6 seconds, compare this to a free editor like Notepad++ and the difference becomes clear. Now, its true that UltraEdit is full of wonderful capabilities, but a code - text based editor should be as fast as possible as for the most parts we use it for very simple editing tasks.
Eitan Michaelson.
Wondered what happen to the fast and light editor I used to like.
I've been using UltraEdit for years and I can't really put my finger on the exact version but I feel that the editor is getting heavy and loading speed becomes slower with time.
Just got a new Lenovo Yoga 900 laptop with Windows 10 , loading takes sometime 5 or 6 seconds, compare this to a free editor like Notepad++ and the difference becomes clear. Now, its true that UltraEdit is full of wonderful capabilities, but a code - text based editor should be as fast as possible as for the most parts we use it for very simple editing tasks.
Eitan Michaelson.
I'll add a vote to UE (v24 x64) taking far too long to open. On a mobile workstation with a i7-6820 @ 2.7GHz, 32gb ram, and a blazing fast Samsung Evo 960 1tb NVMe drive, it takes 9-10 seconds to open. Something is very, very wrong.
The default directories were to my domain user "folder redirection" paths and I changed them to fixed local directories to make sure the redirected folders weren't slowing UE down.
The default directories were to my domain user "folder redirection" paths and I changed them to fixed local directories to make sure the redirected folders weren't slowing UE down.
There must be something wrong on your PC as UE v24.00.0.49 starts on my machine with a much slower hardware within 2 seconds.
Since UE v24.00 the file startup.log is created in %APPDATA%\IDMComp\UltraEdit for finding out what causes delays on startup of UltraEdit. You could investigate this file by yourself or report the startup issue to IDM support and attach this log file for investigation by IDM.
Since UE v24.00 the file startup.log is created in %APPDATA%\IDMComp\UltraEdit for finding out what causes delays on startup of UltraEdit. You could investigate this file by yourself or report the startup issue to IDM support and attach this log file for investigation by IDM.
Best regards from an UC/UE/UES for Windows user from Austria
I have seen UE64 getting slower and slower over recent times. It can take anywhere from 30 seconds to several minutes to start on my PC (Lenovo Carbon X1, quad core i5-4200U CPU @ 1.60GHz, 8 GB RAM, SSD drive), and when it does load, often uses 5-25% CPU time just sitting there with no files open. Other applications load very quickly (eg Visual Studio 2017 takes less than 5 seconds to load).
If I hover my mouse pointer over one of the toolbar icons (eg print preview button), UE64 maxes out one of the CPU cores. Crazy.
I've tried all the fixes mentioned in this thread with no great improvement. Deleting the stuff in the appdata folder made an improvement initially but after a day or two the usual slow performance returned.
I've run a procmon trace, but it's difficult to understand it since it is huge (millions of lines relating to UE64 just during a startup operation).
One little glimmer of hope - I did notice tonight that if I run UE64 as administrator, the load time is only a few seconds and CPU usage when sitting with no open files is almost zero. My user account is a member of the administrators group, so it shouldn't make any difference, but there seems to be some permissions issues while running normally.
If I hover my mouse pointer over one of the toolbar icons (eg print preview button), UE64 maxes out one of the CPU cores. Crazy.
I've tried all the fixes mentioned in this thread with no great improvement. Deleting the stuff in the appdata folder made an improvement initially but after a day or two the usual slow performance returned.
I've run a procmon trace, but it's difficult to understand it since it is huge (millions of lines relating to UE64 just during a startup operation).
One little glimmer of hope - I did notice tonight that if I run UE64 as administrator, the load time is only a few seconds and CPU usage when sitting with no open files is almost zero. My user account is a member of the administrators group, so it shouldn't make any difference, but there seems to be some permissions issues while running normally.
- Hovering mouse over File New button...
![UE64 cpu usage.png (71.03KiB)]()
Geoff_S, it looks like another process running in background or a file/directory permission problem is the cause of long startup time of UltraEdit on your machine.
I suggest to click in Windows Task Manager on tab Startup, uncheck all items, restart Windows and check if UltraEdit starts now within 2 seconds (on opening just 1 file and not 100 files). Find out via re-enabling items again on Startup tab of Windows Task Manager which application/process is responsible for the delays on starting UltraEdit and opening files. Usually the list of applications started on start of Windows contains about 50% applications which the user will not miss when not being started automatically.
In case of file/directory permissions is the cause of long delays on starting UltraEdit, use the filer options of Process Monitor. The toolbar of Process Monitor contains on right side 5 symbols to enable/disable global filters. I suggest to toggle off all filters except Show File System Activity (filing cabinet symbol).
Next right click on columns header line of Process Monitor, left click on Select Columns and enable Duration. The Duration column is added as last column. Click with left mouse button on column header, hold left mouse button and drag the column to the left, for example between Date & Time and Process Name. You might need to do this in two steps depending on width of columns and width of Process Monitor window (screen width). This column displays the time needed for each logged action in seconds with a microseconds resolution.
Clear the current log with Ctrl+X, start UltraEdit, switch back to Process Monitor and stop capturing with Ctrl+E. Next press Ctrl+S, select Events displayed using current filter and uncheck Also include profiling events and select as format Comma-Separated Values (CSV). Then save the record. Start a spreadsheet application like Excel or Calc and load the UTF-8 with BOM encoded CSV file using comma as separator. Sort the rows in the spreadsheet application by Duration column. Now you should easily see what causes the long delays and look in Process Monitor with lines sorted as recorded what are the file system activities around the ones needing long time to finish.
Of course it is also possible to open the CSV file in UltraEdit, convert the CSV file to fixed width and sort the lines in now fixed width file according to columns of Duration. So you don't need a spreadsheet application installed at all to analyze the log of Process Monitor.
I suggest to click in Windows Task Manager on tab Startup, uncheck all items, restart Windows and check if UltraEdit starts now within 2 seconds (on opening just 1 file and not 100 files). Find out via re-enabling items again on Startup tab of Windows Task Manager which application/process is responsible for the delays on starting UltraEdit and opening files. Usually the list of applications started on start of Windows contains about 50% applications which the user will not miss when not being started automatically.
In case of file/directory permissions is the cause of long delays on starting UltraEdit, use the filer options of Process Monitor. The toolbar of Process Monitor contains on right side 5 symbols to enable/disable global filters. I suggest to toggle off all filters except Show File System Activity (filing cabinet symbol).
Next right click on columns header line of Process Monitor, left click on Select Columns and enable Duration. The Duration column is added as last column. Click with left mouse button on column header, hold left mouse button and drag the column to the left, for example between Date & Time and Process Name. You might need to do this in two steps depending on width of columns and width of Process Monitor window (screen width). This column displays the time needed for each logged action in seconds with a microseconds resolution.
Clear the current log with Ctrl+X, start UltraEdit, switch back to Process Monitor and stop capturing with Ctrl+E. Next press Ctrl+S, select Events displayed using current filter and uncheck Also include profiling events and select as format Comma-Separated Values (CSV). Then save the record. Start a spreadsheet application like Excel or Calc and load the UTF-8 with BOM encoded CSV file using comma as separator. Sort the rows in the spreadsheet application by Duration column. Now you should easily see what causes the long delays and look in Process Monitor with lines sorted as recorded what are the file system activities around the ones needing long time to finish.
Of course it is also possible to open the CSV file in UltraEdit, convert the CSV file to fixed width and sort the lines in now fixed width file according to columns of Duration. So you don't need a spreadsheet application installed at all to analyze the log of Process Monitor.
Best regards from an UC/UE/UES for Windows user from Austria
Maybe UltraEdit has a problem with some mobile workstations, since I have similar specs to jimbob_sf's (i7-6700HQ @ 2.6 GHz, 32 GB RAM, Samsung 1 TB NVMe, 4K display, Windows 10 Pro). NO other program loads that slow (e.g. LibreOffice Portable loads within 2-3 seconds, Notepad++ Portable in an instant). My "solution": I switched back to UltraEdit 16.20.
You all are not alone.
I have a Surface Book with an Intel Core I7, 8GB of RAM, SSD, and dedicated GPU. It is a fast and clean machine. I don't run Anti-Virus or any other background programs to slow it down.
It takes 13 seconds for UltaEdit to start. Notepad++ takes less than a second.
I have UltraEdit deployed on almost twenty other PCs in my business, and some startup times are less than two seconds, while others are as bad as the Surface Book. I've been using UE for 10+ years. The issue started occurring several versions ago. I think it began with the 64 bit change over. I don't remember exactly though.
There is clearly an issue that IDM needs to address. I have had several exchanges with the official support staff over this, but I eventually gave up as the time I was wasting on tracking it down significantly exceeded the time I am spending waiting for it to load. I just keep it running all the time and restart when there's an update. The official support staff has always been excellent with all support issues.
In this thread I've seen the response, "it's not happening to me so it must be your machine" numerous times. That would make sense if it were an isolated problem. It is clear that it is not an isolated problem. limited to a few users. Even if it was...that does not mean that UE isn't to blame. Just because it isn't happening to you, doesn't mean there isn't an issue.
I will be trying some of the suggestions mentioned on this thread...if I can find the menu items in the latest version.
I have a Surface Book with an Intel Core I7, 8GB of RAM, SSD, and dedicated GPU. It is a fast and clean machine. I don't run Anti-Virus or any other background programs to slow it down.
It takes 13 seconds for UltaEdit to start. Notepad++ takes less than a second.
I have UltraEdit deployed on almost twenty other PCs in my business, and some startup times are less than two seconds, while others are as bad as the Surface Book. I've been using UE for 10+ years. The issue started occurring several versions ago. I think it began with the 64 bit change over. I don't remember exactly though.
There is clearly an issue that IDM needs to address. I have had several exchanges with the official support staff over this, but I eventually gave up as the time I was wasting on tracking it down significantly exceeded the time I am spending waiting for it to load. I just keep it running all the time and restart when there's an update. The official support staff has always been excellent with all support issues.
In this thread I've seen the response, "it's not happening to me so it must be your machine" numerous times. That would make sense if it were an isolated problem. It is clear that it is not an isolated problem. limited to a few users. Even if it was...that does not mean that UE isn't to blame. Just because it isn't happening to you, doesn't mean there isn't an issue.
I will be trying some of the suggestions mentioned on this thread...if I can find the menu items in the latest version.
I asked IDM support by email after installing release candidate 1 of UE v24.00 and running it why the file %APPDATA%\IDMComp\UltraEdit\startup.log is still created by release candidate as it was also done by the beta versions because the UE developers made many improvements for faster starting UltraEdit with lots of files in beta versions of UE 24.00. I received the reply that IDM Computer Solutions, Inc. is aware of long startup times reported by some users (of about 2 million UltraEdit users) on their machines. Therefore creation of this log file is kept in release candidate and later also in public released UltraEdit v24.00 in the hope that UltraEdit users who encounter long startup times of UltraEdit send this file by email to IDM support.
I'm also a developer for more than 20 years. I know from my experience that an issue being reproducible on developers machine is easy to fix in code. But an issue which occurs only on some machines not reproducible by the developer on his machine is really very difficult to fix. It is possible to fix also such issues, but it is very very difficult. Any information is helpful.
Send %APPDATA%\IDMComp\UltraEdit\startup.log or even better the entire directory %APPDATA%\IDMComp\UltraEdit\, let Process Monitor record every registry, file system and network access on startup of UltraEdit and send the saved Process Monitor log file (native format) compressed with ZIP or RAR to IDM support by email (or a link on having it uploaded anywhere). The more users suffering on several seconds UltraEdit startup times transmit as much data as possible recorded during the startup is helpful for the UltraEdit developers to isolate the issue and hopefully finally fix it.
I know from IDM support that the long startup time of UltraEdit on some machines is a very high priority issue. But the developers failed up to now to isolate the issue and find the reason. But at the moment the UltraEdit developers are in the dark regarding the long startup time of UE on some machines.
I could image that the long startup delay occurs only on very fast machines. I encountered this one times on one of my software where a thread management was coded wrong resulting in long delays on a very fast machine. The started thread finished before main task was ready to recognized the thread finishing signal and therefore run in thread finishing timeout which was several seconds. That was of course caused by wrong initialization of the thread in main task code, but was really hard to find out by me. I needed first to find out where exactly the long delay occurred before I could fix the issue by just looking on code as the debugger on my development machine was of no help on this issue.
I'm also a developer for more than 20 years. I know from my experience that an issue being reproducible on developers machine is easy to fix in code. But an issue which occurs only on some machines not reproducible by the developer on his machine is really very difficult to fix. It is possible to fix also such issues, but it is very very difficult. Any information is helpful.
Send %APPDATA%\IDMComp\UltraEdit\startup.log or even better the entire directory %APPDATA%\IDMComp\UltraEdit\, let Process Monitor record every registry, file system and network access on startup of UltraEdit and send the saved Process Monitor log file (native format) compressed with ZIP or RAR to IDM support by email (or a link on having it uploaded anywhere). The more users suffering on several seconds UltraEdit startup times transmit as much data as possible recorded during the startup is helpful for the UltraEdit developers to isolate the issue and hopefully finally fix it.
I know from IDM support that the long startup time of UltraEdit on some machines is a very high priority issue. But the developers failed up to now to isolate the issue and find the reason. But at the moment the UltraEdit developers are in the dark regarding the long startup time of UE on some machines.
I could image that the long startup delay occurs only on very fast machines. I encountered this one times on one of my software where a thread management was coded wrong resulting in long delays on a very fast machine. The started thread finished before main task was ready to recognized the thread finishing signal and therefore run in thread finishing timeout which was several seconds. That was of course caused by wrong initialization of the thread in main task code, but was really hard to find out by me. I needed first to find out where exactly the long delay occurred before I could fix the issue by just looking on code as the debugger on my development machine was of no help on this issue.
Best regards from an UC/UE/UES for Windows user from Austria
Same problem here. My PC is a Thinkpad P51 with a 4K display with a resolution of 3840x2160 with 64 GB RAM and NVME SSD.
The UltraEdit v24.10 startup takes at least 13 seconds. The attachment contains the startup.log and in which I found this line:
[2017/08/17, 14:45]: Executing CEditMain::InitialShowWindow: 12.4530
Setting the high DPI setting to "system(...)" in properties of UE shortcut (see image in attached ZIP file), lets UE start in a second.
On using default high DPI setting it takes 14 seconds to startup UltraEdit.
The UltraEdit v24.10 startup takes at least 13 seconds. The attachment contains the startup.log and in which I found this line:
[2017/08/17, 14:45]: Executing CEditMain::InitialShowWindow: 12.4530
Setting the high DPI setting to "system(...)" in properties of UE shortcut (see image in attached ZIP file), lets UE start in a second.
On using default high DPI setting it takes 14 seconds to startup UltraEdit.
- StartupLog_ShortcutProperties.zip (76.11 KiB) 116
- ZIP file contains startup.log and screenshot of Chinese shortcut properties.
- 7
Does anyone know how to use high DPI (in English). The previous post about this by Yanqing had an attachment that was in Chinese. This slow load time with a 4K monitor may be the problem I am having too.
I think what you are looking for looks like this in the English version of Windows and UltraEdit. The setting is Override high DPI scaling behavior.
Cheers...
Frank
Cheers...
Frank
- Compatibility settings in properties of UltraEdit shortcut file.
Kurk likes this post
- 7
Thanks so much. It helped. On two monitor computer with second monitor a 4K monitor the load time went from 7 seconds to about 4 seconds. On my traveling computer with 4K screen the load time went from about 6 seconds to 4 seconds. BTW: Word loads in about 4 seconds.
Just to put things in a meaningful perspective: I switched from KEdit to UltraEdit about 6 months ago. KEdit loads so fast I cannot measure it. Obviously UltraEdit does not. I have come (an ongoing process) to being OK with my decision, but I wish the load time was faster.
Just to put things in a meaningful perspective: I switched from KEdit to UltraEdit about 6 months ago. KEdit loads so fast I cannot measure it. Obviously UltraEdit does not. I have come (an ongoing process) to being OK with my decision, but I wish the load time was faster.
A question on those using 4K displays: Do you have ever tried the UltraEdit Classic theme?
See my post about Classic desktop theme variants and my post about puristic look like Windows apps have by design.
By the way: I know from IDM support that the issue reported by Yanqing is interesting for IDM too. It seems that having text scaling (in Windows) set to 250% will cause a slow startup. Resolution is not a factor. Lowering scaling even to 200% alleviates the problem.
bersch replied on the question above: I used Classic theme, it didn't make much difference. But the solution suggested by Yanqing reduced my start time from 7-8 s to 1-2 s. Well done!
I replied: bersch, thank you for answering my question, much appreciated. On running a macro or script with many window refreshes it makes a big difference if Classic theme (in Windows 2000 application look) is used or one of the stylish themes.
See my post about Classic desktop theme variants and my post about puristic look like Windows apps have by design.
By the way: I know from IDM support that the issue reported by Yanqing is interesting for IDM too. It seems that having text scaling (in Windows) set to 250% will cause a slow startup. Resolution is not a factor. Lowering scaling even to 200% alleviates the problem.
bersch replied on the question above: I used Classic theme, it didn't make much difference. But the solution suggested by Yanqing reduced my start time from 7-8 s to 1-2 s. Well done!
I replied: bersch, thank you for answering my question, much appreciated. On running a macro or script with many window refreshes it makes a big difference if Classic theme (in Windows 2000 application look) is used or one of the stylish themes.
Best regards from an UC/UE/UES for Windows user from Austria
