SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: Ian P on April 16, 2008, 12:05:39 am

Title: Intermittent unresponsiveness
Post by: Ian P on April 16, 2008, 12:05:39 am
Was there ever any resolution to the "Help! slickedit suddenly hang very often" topic ( (

In that topic pchandra posted "I see something similar several times a day, and I've noticed it since v10. For no apparent reason, SlickEdit will lock up and not respond to screen repaints for maybe 15-20 seconds, then it comes back completely responsive. ... it happens all the time.", and the last posting in the topic was a request for information from SlickEdit tech support.

I'm still regularly seeing the same problem with SE 2007 12.0.3, and its very annoying so it would be nice to get a fix or workaround for it.
Title: Re: Intermittent unresponsiveness
Post by: chrisant on April 16, 2008, 03:28:25 am
Can you offer any information that would help SlickEdit tech support or the devs track down the issue?  So far I've been able to trace any hangs I've seen back to either autocomplete or scanning the hard drive for the 12,000+ files in my workspace (split into 4 projects of 2K, 1K, 1K, and 8K files).  I think both of those are known issues, with varying degrees of mitigations available.  If you can narrow down the seemingly random hangs a bit, I'm sure it would help the SlickTeam investigate the issue.  I mean, what if there is something set special on your machine, or an interaction with another program or system component (AV scanner, who knows) that is specific to your machine?  The SlickTeam wouldn't be able to reproduce the problem and wouldn't be able to track it down.  So if we can help them help us, I'm sure it will benefit all parties quite a lot.  :)

By the way, @SlickTeam: can I suggest a "stop after (ms):" limit for auto-complete?  I'd probably set it to about 200ms, as I really like auto-complete, but I really don't like having my typing rhythm interrupted for more than a fraction of a second.  In fact, if I type a key while auto-complete is building its list, ideally I'd like the editor to interrupt the list-build, process my keystroke, and then possibly continue the list-build if appropriate.  The existing configurable limits are certainly needed (no one wants an auto-complete list with 14,000 matches ;)), but they only indirectly limit the performance cost, and it would be nice to have more direct control over the responsiveness.  As always, thanks for listening!
Title: Re: Intermittent unresponsiveness
Post by: Ian P on April 16, 2008, 11:29:06 pm
Its very hard to say just what happens to provoke it when it happens. When editing C files I see occasional short pauses when I click on a name (variable name, function name, etc.) but these are usually only 1 or 2 seconds, which is a little annoying but livable-with. Sometimes I'm just moving the mouse and this happens, apparently as it moves over a name. On a mouse-over of these names SE pops up a message with some info about its declaration, so I assume that the delay probably happens as its looking that up.

What provokes the longer delays, which can sometimes be 10-20 seconds or more, I really don't know.

The only things that may be special/unusual about my environment would be that I do work with a couple of very large projects with hundreds of files, and one of them is located on a remote machine accessed via a networked samba drive.
Title: Re: Intermittent unresponsiveness
Post by: chrisant on April 17, 2008, 07:40:17 am
Ah.  Yes, the short delays you describe seem to match up with when the editor looks up tagged symbols to build tooltips, etc.

I suspect that the longer delays occur when the editor looks up the symbol under the cursor and then shows it in the Preview toolbar.  In order to show it in the Preview toolbar, it is going to need to load the corresponding file.  If the corresponding file is on a network drive, then any slowness in the network will directly manifest as pauses in the editor*.

Can you try something:  Do the pauses still occur after you close the Preview toolbar (close it; auto-hide isn't enough) and turn off tooltips?  To turn off tooltips, open the Options dialog and go to the Context Tagging node for the language you're using, and uncheck the "Show info for symbol under mouse" checkbox.

* The editor could potentially mitigate network problems by using a background thread to load the files, but (a) that can get complicated and lead to its own set of issues, (b) I don't know if SE is multi-threaded enough for that (maybe it is, maybe no, I do not know), and (c) persistent network problems would either result in a buildup of hung background threads (if loads occur in parallel) or all subsequent background local loads bottlenecking against the network load (if loads are serialized on a background worker thread).  It may be that the best solution is to turn off the features entirely.

@SlickTeam: If there is a way to detect with relatively high confidence whether a file is "remote", then perhaps a def_no_background_remote_loads setting (bad name :P pick a better one) could restrict the editor to only load local files and thus avoid the most common cause for pauses?
Title: Re: Intermittent unresponsiveness
Post by: dunkers on April 17, 2008, 10:04:08 am
Just gotta say I'm browsing this webby and click the 'new' button for this thread, and.... nothing. Had to wait nearly a minute for the page to show  ::)
Title: Re: Intermittent unresponsiveness
Post by: Ian P on May 03, 2008, 12:21:21 am
I turned off tooltips as suggested by chrisant above (I never have the preview toolbar/window open) and have been working like that for the last couple of weeks, and its been behaving very well - no noticeable hangs. So today I turned tooltips back on and almost immediately started noticing hangs of about 5 to 10 seconds again. So it does seem to be tooltips (the "show info for symbol under mouse" setting) that is causing it.

The strange thing is that I've noticed these short hang ups sometimes occur when I'm not actually mousing over anything significant.
Title: Re: Intermittent unresponsiveness
Post by: Dennis on May 07, 2008, 10:12:18 pm
"significant" is in the eye of the beholder.  For example, in Java, mousing over "this.getFirstChild().toString()" may not seem significant to you, but it is a signficant amount of work the editor has to do to evaluate the type of "getFirstChild", locate the right "toString" method and format it's javaDoc comments.

I have added a small amount of result caching to the mouse over stuff for 13.0.1.  That should help with some of the delays.  Real data and real examples would help us isolate the performance issues even more.  Try profiling if you have reproducable cases.
Title: Re: Intermittent unresponsiveness
Post by: hs2 on May 07, 2008, 10:45:35 pm
Hi Dennis,
I've also noticed a somewhat sluggish behaviour of v13 under certain conditions.
It seemed to me that it's somehow related to the Preview TB updating...
However, I've run a test using the Context TB and scrolling through the symbol list to compare v12.0.3 <-> v13.0.0.
In v12.0.3 an immediated update of the Preview TB is done. I've patched v13.0.0 accordingly and it turns out that running the same test case (same file: context.e) causes reasonable lags when scrolling in v13.0.0 and the Preview TB is updated with a javadoc'd symbol. v12.0.3 doesn't show this behaviour and the update is visually immediate.
I've to admit that this not the very best test case/comparison but I think it could be a good pointer to find the performance problem of v13 (javadoc parsing/HTML rendering ?)
Hope it helps finding the problem - good luck,

Edit: I've also used the same (it's always the same) window layout.
Upper Left: Defs TB
Lower left: Symbol props TB: Args
Bottom: Preview TB
Top/Button bar: Context TB
All docked - no autohide.
Title: Re: Intermittent unresponsiveness
Post by: hs2 on May 07, 2008, 11:04:42 pm
Hmm - I've applied the latest hotfixes - should have done it before writing lengthy posts  :-[ - and the performance problem described before went away..
Thanks a lot ! Seems that I can really start using v13 now :)