Slow with Code Highlighting

Stefan_E · Jan 08, 2010#12010-01-08T02:46+00:00

A while ago, I complained here how slow UE was with XML files of 2MByte or so. (I don't find the post anymore, I guess Mofi deleted it in line with the forum rules...); Somebody replied that he had no problem and when I tried again, I was doing fine also - probably on a different file than when I complained, but similar size ....

Today, I load a c file of 3MByte and scrolling is extremely sluggish, even if I switch off code highlighting. However, if I rename that file to .foo, so that it's not ever recognized as a known file type, scrolling is fast as it should be... So I conclude that the sluggishness is not related to .xml or .c but to specific structures within the file (plus of course a minimal size to make the bad programming visible...)

If I enable c code highlighting on the file called .foo, it gets again intolerably slow and sticks with that until the file is closed and reloaded (revert-to-saved, confirming to loose a trivial change, is not sufficient).

Running 15.20.0.1022 on Win-7 with plenty of free memory.

Anybody else similar experience? Thanks for your help!

Stefan

Mofi · Jan 08, 2010#22010-01-08T09:45+00:00

With your version of UE syntax highlighting is done with a background thread and so you should be able to scroll always fast. However, with enabling syntax highlighting also searching for function names and code folding is also enabled. Well, both should be done also in background threads in your version of UltraEdit.

To determine the problem I suggest following:

Scroll your *.c file with everything enabled.
Do the same, but with code folding disabled in the configuration dialog.
Backup your wordfile for C/C++, open the wordfile used and remove the function strings to disable function name searching.
Disable syntax highlighting for this C file completely by selecting View - View As - No Highlighting.
(XML files can be analyzed additionally by the XML Manager feature.)

You have written that the C file scrolls slowly also when syntax highlighting (+ function names searching + code folding) is disabled, but when changing the file extension it scrolls fast. In this case it could be that another background application is preventing UltraEdit to load the file data fast. Maybe your anti-virus software is scanning the file when UltraEdit loads the data causing the delays when scrolling.

I'm using also UE v15.20.0.1022 and increased one of my C files to over 3 MB. I don't see any big delay when scrolling with all options enabled. Of course my Windows XP 32-bit is configured for maximum performance which means using Windows Classic theme with all in my point of view unnecessary visual effects disabled including the 2 colors in the title bar. Also all not really needed background applications and services are disabled. So my computer is not really a reference because it is far away from a typical installation. This special performance optimizations makes my computer 2 to 5 times faster (depending on the application) as those of my colleagues using the same laptop type (but most of them with faster CPU) under the same operating system as I.

So if you have performance problems, you should take a look on which background processes are running on your computer and look on them if you really need all of them. The WWW offers information for all existing processes and applications. The tools Process Explorer and AutoRuns from SysInternals (Microsoft) are a great help on configuring (= optimizing) a computer to ones needs.

Stefan_E · Jan 08, 2010#32010-01-08T14:32+00:00

Dear Mofi,

thanks a lot for your suggestions - tried them, to no avail.

disabling code folding: no improvement, even after restart of UE
removing function strings from .uew: no improvement, even after restart of UE
switching Win-7 back to Classic (from Aero): no improvement, even after restart of UE (but I didn't reboot)
in each case, SysInternals shows similar activity on C_File.c and C_file.foo; what I do is: I load both files (which are copies of each other except for the file type) and wait long enough that any virus scan should have finished. Then, I move the scroll bar wildly up and down. On the .c file, essentially nothing happens on the UE screen, whereas on the .foo file, the screen moves very quickly. The left peak is from the .c file, the right from the .foo file. (Interesting that the latter creates I/O activity)

The system is otherwise fairly empty (in fact, it is empty except for the background tasks) as shown in the next picture (the IO activity help show where the UE scrolling was done):

CPU is a 3.2 GHz Pentium 4 with 4G installed memory (of which Windows sees 3.25G). The file is from the sqlite amalgation. Btw., Visual Studio has no problem doing fast scrolling and syntax highlighting.

Mofi, I hope they pay you well for the support you are giving here. As IDM keeps maintaining that they can't listen to customers in the forums, I will raise a support request and direct them here. After all, profiling the application is part of it's development, I would think!

Stefan

Mofi · Jan 08, 2010#42010-01-08T16:46+00:00

Well, normally users do not scroll wildly up and down because reading is also required to find the part looking for. Wildly scrolling up and down could really result in longer delays then "normal" scrolling because of all the intercommunications then needed between the main task of UltraEdit and its background threads. Windows is not a real time operating system and the background threads are surely programmed to not often check if the main task has sent them a message to break and cancel their task because a new thread must be started for a different block of the file.

I have also made a snapshot (already removed from the post) of the Process Explorer performance window on my computer while scrolling quickly up/down the not highlighted file (left) and the highlighted file with code folding (right). As you can see no big difference on my computer. I have not tried it yet with your file.

However, you can send an email to IDM with your C file and a detailed explanation what you think is a problem and should be improved.

Stefan_E · Jan 08, 2010#52010-01-08T18:16+00:00

Mofi wrote:Well, normally users do not scroll wildly up and down because reading is also required to find the part looking for.

Well, I'm not entirely stupid

, but a test case for SysInternals is something different from reading the file to understand the content. For real life reading, it's so bad that grabbing the scroll bar, I don't get any useful feedback about where I have moved it to - it's unworkable.
(I'm in touch with Support as I type this)

Stefan

Jan 08, 2010#62010-01-08T23:28+00:00

The issue is confirmed by Ben of IDM support. He writes:

I am not sure when you can expect a fix for this issue. I will make sure that we keep you updated when there are any changes to the status of this issue. I apologize for the inconvenience.

Almost a year ago, I reported a this much more serious issue and got a similar reply - except that I'm waiting for the follow-up to this day. So I don't expect much.

Btw., I went back installing 10.00a on a virtual machine with 512M RAM only, running on a slower CPU: No problems whatsoever with scrolling, even with syntax highlighting (of course there was no code folding in that version, but then, disabling it in 15.20 doesn't help either...)

Stefan - an angry IDM customer

Mofi · Jan 10, 2010#72010-01-10T12:31+00:00

Indeed scrolling in the large C source file (3781KB, 110861 lines) is noticeable slower than in my C file (215 KB, 4060 lines). So there is something which can be improved, although I guess that this is surely not a typical C file. I have never seen such a large C source file and as the comment at top describes, it is created by copying the source of different modules (C files) together into a single file. However, I think the delay on scrolling with the vertical scroll bar is not so big that it is really interfering.

Interesting is that scrolling with PgUp/PgDn with maximum key repeat rate is extremly fast and also scrolling with the middle mouse button and using autoscroll. So the scrolling delay exists only when scrolling with the vertical bar which causes jumps in the file. The vertical scroll bar is based on number of lines and not number of bytes. So on move of the vertical scroll bar the appropriate difference in line number count must calculated and then the file read and searched for line endings to find +X or -X lines to display the new position. Text files have normally not identical line lengths like records in a database file. So simple the forumula

new file position = current file position + X lines * bytes per line

can't be used for text files as used in database files. But I agree the scrolling with the vertical bar could be nevertheless faster. There is something in the code of UltraEdit which results in a delay when the file is larger. I played a little with the file size and it looks like vertical scrolling is fast up to file sizes of 512 KB. It could be that 512 KB is the internal file cache size.

About the issue: "UE can corrupt Windows if uedit32.ini is in Windows dir and using backup/restore feature"

There are definitely more important issues to work on than this one. Since UE v10.20 the default location for the INI file for new installations is %appdata%\IDMComp\UltraEdit\. The numbers of users upgrading from pre v10.20 to latest version is surely very small. Those using the backup/restore user customizations dialog is even smaller and those using it with clicking on button Select All without looking on which files are now added to the archive and later restore the entire archive without looking again on the files is extremly small. So I suppose the number of users affected by this issue can be counted with 10 fingers. Sure, the developers could add code to uncheck and disable option Others (= all other files in directory of INI) when the directory of the INI file is equal the Windows directory. But the priority for doing that is extremly low because of the extremly low number of users affected by this issue especially because every affected user can manually avoid the problem.

If you are not happy with UltraEdit and you are angry with IDM, why do you use UltraEdit? There are so many other editors. (Of course surely not so many with such a big list of useful features and definitely no one 100% bug free.)

Stefan_E · Jan 10, 2010#82010-01-10T14:31+00:00

Hi Mofi,

at the risk of getting off-topic here:

there is the moral category on a personal level: I hate being lied upon. As I mentioned in the other thread in this post, I reported a total of five bugs and got five broken promises from support!
there is a business ethic question here: Do they care about my data? - What would we think about an airline who said security was a secondary concern? After all, chances of a crash or hijack are extremely small even with reduced measures... that's the proposition you are arguing for!
there are probably in some jurisdictions legal consequences if you crash a customer machine although you have been made aware of the underlying mechanism beforehand.

Yes, I'm actively looking for alternatives to UE. And yes, it's difficult to find.

Stefan

Mofi · Jan 10, 2010#92010-01-10T16:11+00:00

And it is impossible for programmers to 100% prevent users to something bad. With using Windows Explorer you can damage also the Windows directory, also with WinRar, WinZip and all other programs which let you overwrite files on hard disk. Computer users must use also their brain and think about what they are doing, this a fact you can't change.

Stefan_E wrote:I hate being lied upon. As I mentioned in the other thread in this post, I reported a total of five bugs and got five broken promises from support!

I wrote many bug reports to IDM and other software producing companies and neither IDM nor the other companies have ever replied that the reported bug will be definitely fixed by DATE / NEXT RELEASE. I'm also a programmer and never reply on a bug report that I will immediately look into it and fix it. I'm quite sure that IDM support staff has only replied that the problem could be reproduced and was added to the issues database. They have surely not promised that the problem is fixed in the next release or until ???. And lots of my bug reports have not been addressed till now (IDM and other companies) and also I sometimes never fix small bugs if I don't get time for it.

A text editor is not a security risk for human lifes like the software for an airplane. That's the reason why UltraEdit is cheap (just a few dollars) while the software for airplanes costs millions of dollars. I'm programming for Windows applications (operating tool for our devices) as well as firmware for our protection devices for generators and transformers. Every bug in the firmwares of our protection devices is immediately fixed, but not all minor bugs in the Windows operating tool for the devices. The firmware of the protection devices must be 100% free from known bugs on release, but this quality level is not needed for the Windows tools.

This is my last attempt to explain you that what is a serious bug or a minor problem or what is just a little annoying for some users or is an enhancement request / suggestion for improvement is always under the control of the manufacturer of the software and not the customers. Read carefully once the license agreement of UltraEdit or any other Windows application. No one guarantees the user a 100% bug free application and fixing of bugs in a defined time period and also every license agreement warns the user that the software creating company is not responsible for any damage caused by using this software. If you can't live with such license agreements, shutdown your computer because no software on your computer fulfills your requirements.

pietzcker · Jan 10, 2010#102010-01-10T17:45+00:00

Not to offend anyone, but I couldn't help thinking of this quote by Rich Cook:

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning."

Stefan_E · Jan 10, 2010#112010-01-10T18:01+00:00

lgw · Jun 05, 2010#122010-06-05T20:56+00:00

VI
Of course, the real solution is to hire a c programmer who understands why this is not really an UltraEdit issue.

bulgrien · Jun 06, 2010#132010-06-06T04:05+00:00

Stefan_E wrote:I'm actively looking for alternatives to UE. And yes, it's difficult to find.

Have you tried Multi-Edit? Believe it or not, prices have come down from around $395 ten years ago to about $180 for a single user license (editor only, no compare tool or extras). UltraEdit remains the best bang for my buck... but, if you absolutely need something more, perhaps you will find it worth the higher cost...?