SLick 13.0.1 unresponsive when it gets focus

[jporkka]

This isn't really a new problem, but it seems I'm running into it a lot lately.

When I switch to slickedit I often have to wait several seconds before it responds...it is totally locked up and doesn't even paint its window.
This happens even when I have only local-filesystem files open, and doesn't seem to depend on how many I have open. Typically I will have at most about 50 files open (mostly C++ source code).

I do not have a really consistent repro case, but this probably happens about 50% of the time when I switch to slickedit from doing other things.
Unusually large files doesn't seem to be the problem either (though there are problems handling large files, such as C++ preprocessor output files).
My workspace tag file has 1,400 source files.


What can I do to either help diagnose the cause, or fix it?



SlickEdit Version 13.0.1.0

Serial number: WB337926
Licensed to: joe porkka
Licensed number of users: Single user
License file: C:\ProgramData\slickedit\13\slickedit.lic

Build Date: June 13, 2008
Emulation: Visual C++ 6

OS: Windows Vista or "Longhorn"
Version: 6.00.6000 
Memory: 78% Load, 3223MB/4125MB Physical, 333MB/2097MB Virtual

Installation Directory: C:\Program Files (x86)\SlickEdit 2008\ (non-removable drive,NTFS,315427MB free)
Configuration Directory: C:\Users\jporkka\Documents\My SlickEdit Config\13.0.1\ (non-removable drive,NTFS,315427MB free)
Spill File: C:\Users\jporkka\AppData\Local\Temp\$slk.13 (non-removable drive,NTFS,315427MB free)

Hotfixes:
C:\Users\jporkka\Documents\My SlickEdit Config\13.0.1\hotfixes\hotfix_se1301_cumulative.zip (Revision: 10)

[chrisant]

When you notice that the editor is hung, try pressing Ctrl+Alt+F9.  That should cause the Slick-C interpreter to break and show a Slick-C stack when it gets control back.  So if the hang is inside native code then it ought to break at the point immediately after returning from the native code.  Or if the hang is actually a performance issue inside macro code then it ought to break into the macro during the performance issue.  That may help to begin to track down the issue.

[Graeme]

Hi Chris  - just checking something  - should that be Ctrl-Alt-Shift-F9  - according to this http://community.slickedit.com/index.php?topic=3105.msg12784#msg12784 it should be.

Graeme

[chrisant]

Oops, yes, Ctrl+Shift+Alt+F9.

[hs2]

Ctrl+Shift+Alt+F2 breaks immediately. HS2

[jporkka]

The magic key sequence is ctrl-alt-shift-f2

Unfortunately, this doesn't solve the problem...I still get busy periods.

A couple of times I hit this abort command when switching to Slick and found that it does spend some significant amount of time checking the R attribute on all open files.

It appears to call FindFirstFile() for each open buffer. (It doesn't seem to close the handle, but maybe slick handles that behind the scenes for you somehow?)

Fixing this attribute checking would improve performance for sure, but it isn't the whole problem either
FOr now I've added debug spew to _actapp_ to see if the big delay is happening inside this macro or now, and perhaps which on activate function.

[Lee]

I've seen something like this before, do you have any really large files open?  When getting an app activate message, we do loop through open files to test READONLY status.  I recall once when working with 100MB+ XML files open, SlickEdit would freeze for several seconds before coming back.  When I tried to track it down, I profiled it down to a single win32 call.  Near as I could tell, whatever active virus scanner we were running at the time had taken over and was not releasing the file handle back to us.  Maybe something similar here?

[jporkka]

I don't have any large files loaded currently, and I have my A/V disabled.
I changed call_list to complain about any macro that takes > 1 second to run.

So far, I've seen _actapp_files take over 3 seconds.
Curiously, I switched away from slick and back again, and then this function takes only 2 milliseconds.


How can I narrow this down? Do I have to insert say() statements throughout actapp_files, or is there a better way?

[Lee]

You could certainly try the Slick-C profiler.  I think this example is still correct:

Code: [Select]

_command void test_slickc_profiler() name_info(',')
{
   profile("on");
   doEverything();
   profile("view");
}


[jporkka]

Thanks, the results when actapp_files took > 3 seconds:
_actapp_files2  files.e 10658   1       3144.494        99.999  3144.494        3144.494        3144.494        0.56    0.002   0.56    0.56    0.56
for_each_buffer window.e        2270    1       3120.077        99.922  3120.077        3120.077        3120.077        0.821   0.26    0.821   0.821   0.821
maybe_set_readonly      vc.e    5794    140     3119.946        99.918  22.228  0.509   3029.957        3.398   0.127   0.28    0.24    0.105
file_list_field stdprocs.e      3037    140     3054.442        97.711  21.181  0.85    3029.909        3052.215        97.704  21.180  0.70    3029.907
_isdiffed       stdcmds.e       34513   140     55.533  1.176   0.395   0.369   0.774   55.533  1.176   0.395   0.369   0.774


So file_list_file took just over 3 seconds over 140 iterations - the max time for a single iteration was 3029 - the vast majority of its total time.
Yes, I have about 140 files open, but even so typically it doesn't take 3 seconds to activate slickedit.

So the question is, whats wrong with file_list_file (or really, file_match) ?

[chrisant]

When you switch to SE and it takes a while -- is that generally after you've just finished doing a build?  I wonder if the build is pushing the master file table entries for the 140 files out of the disk cache, and switching to SE hits the physical disk for all 140 files to pull their master file table entries back into cached memory.

Interestingly, on Windows it is possible to use FindFirstChangeNotification/etc to efficiently check for attribute/content changes for the open files without looping over them.

[hs2]

I also thought that SE or the files got swapped out. Hmm - had a 2nd look at the 1st post:
'Memory: 78% Load' - seems that jporkka is a real power user and his system is stressed a bit...
HS2

[jporkka]

It is really looking like there are probably multiple reasons for this performance problem.
chrisant has a good point....I will be watching for that.

However, just now I had VS be slow to take focus several times, just switching between this browser window, outlook and VS. Memory usage is high, but CPU usage is low - idle machine.

I added code from the find first file to tell me which file is slow - so far I've not had that pop up, but from the previous profile I posted here it looked like just one of the 140 FFF calls was slow.

Here are 2 profile reports (just the top items...all other items in the report account from almost nothing) from just now - switching back and forth.
Tag_read_db appears to be really slow tonight, taking over 5 seconds.


_actapp_makefile   project.e   44002   1   5441.140   100.000   5441.140   5441.140   5441.140   0.22   0.000   0.22   0.22   0.22
_MaybeRetagWorkspace   wkspace.e   39688   1   5441.138   100.000   5441.138   5441.138   5441.138   0.277   0.005   0.277   0.277   0.277
tag_read_db      0   2   5438.833   99.994   2719.916   0.59   5438.827   5438.833   99.994   2719.916   0.59   5438.827


_actapp_makefile   project.e   44002   1   5436.683   100.000   5436.683   5436.683   5436.683   0.25   0.000   0.25   0.25   0.25
_MaybeRetagWorkspace   wkspace.e   39688   1   5436.680   100.000   5436.680   5436.680   5436.680   0.264   0.005   0.264   0.264   0.264
tag_read_db      0   2   5433.394   99.994   2716.697   0.66   5433.388   5433.394   99.994   2716.697   0.66   5433.388
_ini_get_section   ini.e   717   1   1.112   0.21   1.112   1.112   1.112   0.12   0.000   0.12   0.12   0.12

[Lee]

If you believe the urban legends that Vista can't fully support and use 4GB RAM, you might be at the limit of the OS with memory loads like that, and are at the mercy of virtual memory being swapped in and out when task switching.  There are a number of system OS calls that occur on an activate app message in SlickEdit, especially for file checks.  It has to do that for N open buffers, and workspace/projects files, and active tag files.  Any one of those could trigger an OS internal to do maintenance and SlickEdit is just waiting for the call to return.

There are some configuration options that you could try changing in Options > File Options > Load > Auto reload that directly affect the operation of _actapp_files.  There is an option Fast auto read only (def-var def_fast_auto_readonly).  It uses a different built-in method of checking if the file is writable,  I make no guarantee that it will be better, but it may yield a different result.   You could also turn of some of the other reload options in that section (def-var def_actapp), if you don't think you will need them.

[jporkka]

The Memory Load value in SlickEdit I think isn't useful on Windows.
I logged off this AM, and logged back in, ran a CMD window, launched VS.
My load was up to 75%.
Then I wrote a program to allocate 5GIG and memset() it all. (64bit vista, 64bit application).
Right after that, the memory load in Slick shows 18%.
What load is apparently measuring is how much of memory is in the working set of running applications and the amount of memory being used by the OS for filesystem cache.
Of course, my 5GIG application caused the OS to dump nearly all the filesystem cache - lowering the memory load dramatically.

WRT 4G and vista: Myth. There are hardware limitations that prevent the OS, any OS, from accessing all memory - since the system BIOS and other things overlap the same hardware address space as some of that memory.

Either way, the perf problems in Slick do not seem to coincide with obvious things like when I build. Last night, as the profile shows, "tag_read_db" was taking a very long time...but only sometimes when switching to slick. The machine was otherwise idle...I was not building or doing much editing...just testing switching between slick and community.slickedit.com

As an additional test, I used that program to malloc(4G) and memset(4g), then switch to slick.
Slick activates very quickly.

So something is clearly wrong, and I don't know how much more troubleshooting I can do from here. It may well be an OS problem, yet Slick is the only application that I use that seems to have this problem (though, clearly, slick behaves differently that msword or outlook of course).

I sent a request to slick edit tech support on monday and have had no response.