Sluggish cursor on Windows

[eda]

SlickEdit is driving me crazy because the cursor is moving slowly. When I press delete then there is delay effect.

I using a powerful Windows Server 2008 lightly loaded. And SlickEdit 18.0.1. I primarily working on C code.
I have tried to close other applications and reboot the machine.

Any suggestions?

[Graeme]

Are keypresses slow in other applications?
How long have you been running slickedit and when did the problem start?

Maybe it's something like this
http://answers.microsoft.com/en-us/windows/forum/windows_7-performance/very-slow-keyboard-response-windoes-7-2008-hp/60710e0f-68cf-483c-8855-a44115753ff0

[eda]

1) Other applications does NOT seem to be affected.

2) It is only in periods. In some periods it is extremely slow and other periods it works normally.

3) I do not recall I had it in the version 17 family. But I cannot say for how long it has affected me.

[Graeme]

Are you able to run performance monitor and check what cpu usage is when it's running slow
http://technet.microsoft.com/en-us/library/cc771692(v=ws.10).aspx

Does it affect all keys equally, including navigation keys like left-arrow?
Do you have to hold a key down for a while for it to take effect?
How long is the delay before a keypress is acted on?
When it's running slow, how long does it stay running slow for - one minute, two minutes, ten minutes ...?
How often does a slow period occur, once a day, twice a day... more than ten times a day...?

[eda]

I have used the Windows Task Manager to check the load. And my machine seems to lightly loaded. Usually <=10% of the resources are used. I am virtually the only user a recent Dell server with 4 core and 12GB RAM.

It seems arrows and also letters  (like a,b,c,....) are affected at least. When I hold up key down for while it takes long time to completely when it is slow. When things works normally then when I slip a key the associated action also stops. This is not how it works when it performs poorly. Not extremely poorly but so slow it is annoying. One of my co-workers
watched too and said: "You cannot live with that."  And he almost right. I have being think about trying another editor.

It is like SlickEdit occasionally does background job and then things are sluggish.
 
I cannot say how frequently it appears a day.

[Graeme]

I'm having trouble understanding your answers - I guess English isn't your native language.

for example

When I hold up key down for while it takes long time to completely when it is slow. When things works normally then when I slip a key the associated action also stops. This is not how it works when it performs poorly.

Do you mean "when I hold key down" ?
What do you mean "it takes long time to completely"  - what is "completely" ?
What do you mean "the associated action stops" ?  Can you give an example of an "associated action".

You didn't answer this question

When it's running slow, how long does it stay running slow for - one minute, two minutes, ten minutes ...?

How many files are there in your workspace?
Do you have background tagging enabled?
Are your source files and tag files stored locally?

Some suggestions

• Try switching back to slick version 17 and see if the problem goes away
• Turn on the slick C profiler - in the macro menu -> slick C profiler -> begin profiling and check the results.  See "profiling" in the help file.  You probably need to stop and restart the profiler every few minutes or so to stop the output getting too big.  When you system starts running slow, wait until it recovers then have a look at the profile to see if there are any "long" times or what it was doing
• Try creating a new configuration folder from scratch.  When you run slickedit, use vs.exe /sc "some-emty-folder" and slick will create a new config.  See if the problem still occurs.
• Use the system performance monitor to check what the system is doing at the time it is running slow.

[eda]

Let me try to explain what is wrong in a simple language.

1. Assume I press the arrow UP key i SlickEdit.
2. Next assume I stop pressing the arrow up after some time.
3. Normally that means SlickEdit will stop scrolling upwards almost immediately. There is no lag.

When I have the sluggish performance then 3) should be

3. SlickEdit keeps on scrolling upwards for quite some time. In other words there is a lag effect.

Is that simple enough for you to understand?

[Graeme]

Is that simple enough for you to understand?

It clarifies it a little bit but it also raises more questions and unfortunately I don't have any more suggestions for you.

[chrisant]

Are you using SlickEdit over a Remote Desktop Connection?

[eda]

Yes. I use a Remote Desktop connection.

Strangely enough things have been working fine today.

[Matthew]

When we see reports of sluggish performance, quite often the culprit is a workspace background tagging job that is never quite completing. But that tends to degrade overall performance, and not a selected subset of operations. But to muddy the waters further, the up/down arrows often seem to have to worst performance since those operations usually trigger display scrolling, which can be an expensive operation if there is color coding or long lines involved. Mix that with a busy background tagging job and you could see delays.

A background tagging job can get stuck and get into a cycle of attempted retagging each and every time the workspace is opened until it finally completes. If that workspace was left open long enough to get to 100%, then it won't need to retag when that workspace is again opened, and you'll see the improved responsiveness.

If you see this delay come back, see if you can figure out which files you've touched recently. (The recently touched files are the ones that get retagged.) That may lead us to a specific file that has some sort of syntax construct that is dragging down the tagging parser. I'm not entirely convinced that is what is happening here, but it's on the "person of interest" list :-)

[chrisant]

Eda says SlickEdit is being used over a Remote Desktop connection.

SlickEdit typically does an excessive amount of unnecessary repainting, which causes congestion over Remote Desktop and can create significant lag.  Even though the SlickEdit program stopped as soon as the key was released, it takes a while for Remote Desktop to transmit all the excessive repainting.

In a recent version SlickEdit started using double buffering, which makes it impossible now to visually observe how excessive the repainting is (we can see neither the scope of the repainting, nor the frequency or number of repaints).

So:

• If the network is being slow in general, then SlickEdit over RDC will have extra lag.
• If SlickEdit is doing a lot of background repaints (e.g. the Defs window updating, or other windows updating, or syntax coloring causing extra updates), then SlickEdit over RDC will slow down.
• If SlickEdit is doing excessive repaints in response to a key, then SlickEdit over RDC will have lag.

[Graeme]

Why would you run slickedit on a remote machine when you can install it locally?

[chrisant]

Working from home?

That's why I do it.  I connect to my employer's network via VPN, establish a Remote Desktop connection to my work machine (which has 60GB of source code and assets on it), and use SlickEdit to edit source code.  Using Remote Desktop I can do builds and run the product and test suites etc as well.  The work computer is 4x+ more powerful than my home computer, so I'd want to use the work computer even if there weren't company policies against syncing source code onto non-company machines.

[eda]

We have placed all our servers in a server room with water, fire, power, and theft protection. And I just do a remote  desktop connection. That means if someone steel my office computer or laptop on the road no important information is lost. If the power goes out in the office no work is lost either.

In addition the central server I am using is more powerful than my local machine which is a Intel NUC that makes virtually zero noise.

So please why run SlickEdit locally!