Performance and new config file

[Wanderer]

SlickEdit Version 14.0.2.2  Build Date: July 08, 2009
Emulation: Vim
OS: Windows XP  Version: 5.01.2600  Service Pack 3
Language: *.cs (C#)

Hello,
I am working on a VisStudio  2008 project with >800 .cs files organized in >30 projects (.csproj).
Over time, something happens to SlickEdit to become 'unusable' for editing C# projects (as has been well reported elsewhere).

I re-started SlickEdit:

Code: [Select]

[C:\Program Files\SlickEditV14.0.2\win]
>vs.exe -sc configThis\
...and performance is back, the editor responds as we all expect it to.
Of course now I am missing all my aliases, my custom toolbars, toolbar layouts, macros, etc.

What is the best way to 'merge' this new, default config with all the good parts of my old config?
Or do I have to start from scratch?

Thanks for any tips.

[Graeme]

Hi wanderer

I haven't noticed any threads about slick being unusable with C#.  Can you point to one of these threads?

Have you tried getting some profiling data and sending it to slickteam as described here
http://community.slickedit.com/index.php?topic=4322.msg17760#msg17760

Sometimes just rebuilding some of the slick macro files can fix a problem.  If you get some of the profiling data as described above, then sort the profile.txt file, you can see some possible candidate files for re-building  e.g. codehelp.e, complete.e, tagrefs.e, tags.e and anything that looks like a c# specific module.  It's probably a long shot but you could try re-building some of these.

Anyway, you should probably first make a backup of the config folder that performs badly, in case slick team need some help from you to figure it out.


At the very least you should be able to use options import/export to transfer your main configuration settings.  It seems unlikely that they could cause an immediate performance issue because you said the problem was gradual.  You might also be able to transfer vrestore.slk.

Maybe you should just try
1. Backup the bad config folder
2. Delete vslick.sta
3. Run slick from the bad config folder

If you have lots of macro files, I can give you some code to automate re-loading them.  Sometimes I add a step 2B to the above and edit vusrdefs.e and set def_macfiles to an empty string and re-load my macro files afterwards.

Graeme

[Wanderer]

Thanks for the reply, Graeme.
This thread
http://community.slickedit.com/index.php?topic=4702.0
contains most of the complaints about performance, with specific references to C# on the second page.

Until I started using a new config today, I was waiting 1 - 10 seconds for SE to decide, after I type "private int s", if it had a symbol that might fit there.  Pressing 'w' 3 times (move to next word, thrice) might take 10 seconds.  I'm not a blazing typist, so I shouldn't be able to outpace the computer.  If I type 'MapCanvasRenderer', and only 'Ma' appears, I wonder what happened to the other keystrokes...  So I wait to see what SE will surprise me with!
I had a nearly default color scheme, with no symbol coloring.
Typing in the Find Symbol window was equally frustrating.  And SlickEdit crashed three times today -- I'm guessing the first crash corrupted some config file, and it couldn't recover well enough to avoid crashing again later after restarting.

I created a "My SlickEdit Config\14.0.2.prev" directory and moved all the files from "My SlickEdit Config\14.0.2" in to it.
I'll look into what I can restore from the previous config to the new one.

[Wanderer]

Sometimes just rebuilding some of the slick macro files can fix a problem

Could you explain that?  Do the .ex files somehow become corrupted over time?  Do the macros accumulate kruft that rebuilding a .e into a .ex file cleans out?

It would be nice if there were a Tools->Options->Lean and Mean button that reset SlickEdit to max performance.  I understand that 'max performance' means different things to different people working with different languages, but there are some setting that are fairly universal in their impact. 

[hs2]

Reloading macro modules might also re-init some global variables/state if the module contains the appr. macro code. See defload/definit in the help.
As far as I remember I was even deleting the corresponding *.ex file to ENSURE a re-load.
I'm not really sure but it seemed that SE only reloads a module when it's newer than it's already compiled *ex. file.
HS2

[Graeme]

Could you explain that?  Do the .ex files somehow become corrupted over time?  Do the macros accumulate kruft that rebuilding a .e into a .ex file cleans out?

I've noticed a "few" times that re-building a macro file can fix a problem.  It's actually one of the few things I dislike about slick is that the state file can appear to become corrupted and isn't solved by restarting the editor.  With most applications, when you restart the app, you start with a new, clean environment, whereas for speed of startup, slick keeps lots of stuff in the state file.  I'm not sure if there's any data in the state file but there's lots of "compiled" macro code (pcode) and configuration data in there that gets written from memory back to disk when slick closes, if you save the configuration.

Re-building a slick installation macro file isn't really a supported function but many people do it, to customise slick.  I guess because slick rewrites the state file from memory back to disk, it's possible the pcode has been corrupted in memory - unless slick uses the .ex files to generate the state file every time.  Re-loading a macro file forces slick to reload the .ex file into memory (I think) but it probably won't re-generate the .ex file if nothing's changed in the .e file.

Also as hs2 said, many modules have a defload function that's called when a module is loaded, and affects the state file.  It's also possible that loading a module does some initialization to global variables that doesn't happen during a normal startup, even if it's not done by the defload function.

Edit : I suspect the "names" table is kept in the state file, not sure, but if so, reloading a module will re-generate the names table entries for that module.

Graeme

[hs2]

loading a module does some initialization to global variables that doesn't happen during a normal startup

Right Graeme, that's what I was going to edit in my previous post...
Some modules just define global/static variables. These are persistently stored in the state file as part of the compiled pcode. If things go wrong and the value of such a variable became invalid and is not catched by some error handling you're doomed...
Until you delete the *.ex file and re-compile and -load the module containing the variable defintion so that it's updated in the state file with the variables set to initial values.
Note that global variables can be easily modified with the 'set-var' command or 'Macro>Set Macro Variable' (w/o this clumsy re-load procedure).
HS2