Script very SLOW

[moneo]

I have opened a 500 lines long textDocument.
Then I start the following simple Javascript

Code: Select all

i=1;
UltraEdit.activeDocument.top();
while (!UltraEdit.activeDocument.isEof())
{
   UltraEdit.activeDocument.gotoLine(i,1);
   i++;
}

This script moves the cursor beginning from the 1st line till the last line (in the 1st column).

It's extremly SLOW.

If I begin to move the mouse-cursor above the text, then the script runs much faster.
What happens? How could I achieve a fast script running without the mouse-cursor moving?? Could anybody help?? Thanks

[Mofi]

Why do you not use UltraEdit.activeDocument.bottom();? Do you want to count the lines?

[moneo]

Why do you not use UltraEdit.activeDocument.bottom();? Do you want to count the lines?

I want to go line by line towards the end of file, and I do several manipulations on each line. I did not want to tell it in detail, because this is not relevant. Relevant is, what I have written.

Why is this script so extremly slow, and why becomes it faster by mouse-cursor moving?

[Klaatu]

I guess your definition of "extremely SLOW" is relative. I timed it on my rig and it took approx. one quarter second per line without any kind of "mouse-cursor moving", whatever that means. I suspect it becomes faster when fewer updates are needed to redraw the window.

[Mofi]

UltraEdit.activeDocument.key("HOME");
UltraEdit.activeDocument.key("DOWN ARROW");

is maybe faster than gotoLine. Normally large changes on every line are done with a regular expression "search and replace all" which is much faster than manually editing every line.

Why becomes it faster by mouse-cursor moving?

Well, I don't know. Maybe because of JavaScript was developed for HTML and can act also on mouse events and so the engine always waits a few milliseconds after every command for a possible mouse event.

[roland]

I think the problem is that UltraEdit is forcing the display to update after every function call. I don't think it should do this. It's been a while, but last I checked browsers definitely don't do this either. The only time a browser repaints the screen is at the end of javascript execution (usually after each event handler is called).

This just further exposes how the current scripting engine is a tiny wrapper around the existing macro processor. What's really needed is the ability to navigate the document independently of what's displayed in the editor.

[Skwerm]

I've written a script that searches through a file, conditionally pulls specific information from certain lines, re-arranges the data, and then appends the processed text to a new document.

Normally I would have written a .Net console app to do this, but I was excited to try UE's new scripting. Unfortunately, the speed and limitations of UE's Javascript is not up to the job at this point.

The data file I processed was 67,000 lines long and the file UE created was 27,000 lines. The processing took almost 15 minutes on my 3.4GHz P4 with 2Gb RAM. If I'd written a console app I'm sure it would have been able to do the processing in a matter of seconds.

I realize that UE's scripting is brand new and that it'll be improved over time. But until the processing speed is improved and the bugs and missing functionality is addressed I'll probably just go back to macros (for small operations) and use other technologies for processing large files.

[Bego]

Hi Skwerm,

I agree.

When Ver. 13 came out, I saw the new javascripting-possibility and thought: Cool, a real programming environment with variables etc. and no more macros
And in general I still think so, but there are some very annoying things about scripting:

- disastrous performance ( with mouse movements while playback, it is really a bit faster :-/ )
- half-cocked statements ( closeFile with a Parameter ?)
- missing very important BASIC-properties like current col / row, current document-index

Let's hope there will be big improvements here soon.

rds Bego