Miklos wrote:... from time to time after having navigated to or saved a middle size file (above 5000 lines) ...
This is an indication that from time to time
the network access or the server is not responding immediately on a file access triggered by UltraEdit.
For example with File change detection
being enabled as by default, UltraEdit periodically and on switching focus to another file makes a file system access to get file status (file size, last modification date, ...) to determine if the file was modified while opened in UltraEdit. Disabling this feature avoids all those file system accesses being network and server accesses on a file not opened from a local storage media.
Another common source for unexpected delay on accessing a file is an anti-virus application updating itself in background multiple times within working hours. Some anti-virus applications block any file access while switching from previous to new database which can take some seconds and the user is wondering why an application is not responsible for some seconds. Applications like UltraEdit having opened multiple files which are often permanently modified and writing those modifications to storage media (for not losing too many changes on a crash or unexpected power loss) are more affected for such file system delays by background process, heavy network peaks, short high server loads, etc. than other applications loading once everything into RAM, modify it there and save the data back to storage media only on file save.
There is the topic Painfully slow response when connected via VPN
with suggestions which settings to change to decrease file accesses to a minimum.
Some of those file accesses are done by UltraEdit already within separate threads to let main thread be responsive. But others still cause sometimes noticeable delays. Those should be encountered by users and reported to IDM support by email, best with a suggestion how to improve UE/UES for a specific issue.
The free tool to use for analyzing the cause of reproducible delays on responsiveness is Process Monitor
from Sysinternals (Microsoft). But it is not really possible to find out the reason for delays on responsiveness with that tool when they occur only from time to time
. You must have luck to log registry, file system and network accesses with nearly no other process excluded with Process Monitor just while having a delay on responsiveness in one application not occurring frequently.
But I can confirm that the stylish user interface of UE for Windows v23.20 takes much more time for redrawing than the former GUIs, especially those using MFC 6.0 (UE for Windows < v15.00). On my own tests I could see that my UE GUI configuration using Windows Classic desktop theme and UltraEdit Classic theme in Windows 2000 look (more precise in Windows 95 look) with minimalistic workspace makes really a big difference in window refreshing rate. I'm always shocked how much slower UltraEdit is with the default very stylish interface when using for a test the default settings in comparison to my settings on my quite old computers. Well, I favor always functionality over look. The best application for me is the application which I can use fast (by using mainly keyboard). But for others the look is more important than everything else. The majority of UltraEdit users wanted a stylish look which of course needs CPU power (= time for calculation) according to the results of opinion polls in the last 5 years from what I get informed by IDM support after my asking by email. With my interface setting UltraEdit can fill most rectangle areas with one background color (no pixel color calculation needed) and write the text in one color (no cleartype active) over it. That is fast. Shading and fading effects with special cleartype text drawing and icons with alpha channels need of course much more time because for each pixel in window the color must be really calculated first. And UHD or high resolution screens have really a lot of pixels.