Wednesday, February 6, 2008

Slow SlickEdit, Part II

So I was using SlickEdit since the day I started at Google, and forever was plagued by occasional insane slowness. (The original post is here:

The nasty part is it's not always reproducible - the PC I am editing stuff on runs XP, but the source itself resides on a Linux box, where it's shared over SMB, and apparently sometimes the network authentication server at Google goes to some legacy mode, which XP only uses after timing out on the newer one, which makes this particular type of SMB request that SlickEdit makes to the file system on the server intolerably slow.

I've traced some of its slowness to dynamic makefile menus, and disabled these. Today I think have solved the other really nasty problem - occasionally SE will enter the mode where on every opening paren following a function name it would freeze for 5-10-15 seconds, before the paren would even appear on the screen. It was driving me up the wall.

So I ran netmon and looked at what was happening. It turned out that it was opening large amount of really big files - and these files weren't even open in the editor, although I've had them open a few days ago.

I immediately suspected tagging, and disabled it, but it did not change anything. Then I started looking at the autocompletion logic (Tools->Options->File extensions setup->Autocomplete). Disabling autocomplete did not help, but the pane right next to it was called tagging.

Parameter information looked promising, so I disabled the entries under there, and - lo and behold! - it worked! I can now type function calls without 5-10 second interval.

After a quick binary search I narrowed the actual problem to the "Auto-list compatible parameters". I have no idea what this is used for, but disabling it made all the difference for me.

Less features == more useful editor.

I am wishing for a simple text mode editor that would run on Linux (so I could use it with putty), have efficient tagging, and have normal Windows-like (or at least configurable) key mappings and cut and paste concepts, i. e. != emacs. Oh, yes, and the debugger should be integrated.

Any one up for writing Turbo GCC?


dimrub said...

It is true SE takes time to learn and to tune, and that its documentation and support suck, but other than that it absolutely rocks. The speed with which I can write and browse code in it is priceless.

Alex Efros said...

Try VIM. ;-) It has windows version too (and my girlfriend using it!). It fully configurable and doesn't as scary as it looks like at first glance. After I switched to VIM many years ago I feel happy all of time I using it, because it amazingly fast, have all possible features I need both for writing code and writing text, and allow me to edit code/text much faster than with any other editor I tried before.

Sergey Solyanik said...

I remember the last time I switched the editor - in 1996 - from Norton editor to VS-style, it was no fun at all. My fingers hurt for a month!

That's the problem with VI[M] - everything is so completely different, the adaptation would be insanely painful.

Alex Efros said...

Yeah, you right. But UNIX technologies proved to be much more stable than Microsoft technologies. For example, if you had learned Vi 20 years ago chances are you still will be using it nowadays. So, maybe it has sense to spend time learning something which you can use in next 10-20-30 years. :)

Also - take a look at ACME (just google for "Acme: A User Interface for Programmers"). Personally I failed to understand how to use it, but a lot of respected old school people (including Pike) use it nowadays, so maybe they just understand something which I doesn't understand yet. There also windows version, AFAIK: .


dzembu said...

Notepad still works for me...

Anonymous said...

For which language do you use Slick?
For c++ autolist - completes member functions/parameters and autolist compatible parameters - works this way:

if you have a function:
int axc(CD *);

if you will type axc(
then autolist compatible parameters will show you a list of all variables of type CD*...

What is the size of your project?

If you use C++ it is worth to insert to tagger some of your macros it might help...
tools->tagfiles->options->c preprocessing.

also you can try to remove from tagging the parts of stl which are irrelevant for you (i.e. BC support)

also playing with tagging options (in the same panel where C preprocessing might help). You can set better timeouts for showing completions...

One of the problem I ve found with slick is that it does not completes base class members when doing completions for inherited class. It is annoying...

Sergey Solyanik said...

Project size is 30-40k files.

zs said...

thanks... i was stuck with the same issue, and it looks like turning off auto-display parametere info solved it.

Scott Westfall said...

I'm a SlickEdit employee and have some ideas that might help.
1) Check where your workspace and project files are located. Even if your source code is stored remotely, you want your .vpw and .vpj files stored locally. That will also determine the location of your tag file (.vtg). If any of these resources are stored remotely, this would account for the kind of pauses you have described.

2) For a workspace with 30-40k files, you may need to increase your tag file cache size. It should be at least as large as the sum of the tag files used by that workspace, unless that is too much for your machine. You can set that value by selecting Tools > Options, then expanding the Editing > Context Tagging nodes. Set the value for "Maximum tag file cache size(KB)".

You can compute that value by summing the file sizes for all the tag files used. That includes the .vtg file associated with your workspace and the the tag files for your libraries. To find your tag files, select Tools > Tag Files. The first item in the list is the "Workspace Tag File". Look at the location and use your OS to find the size of the .vtg file. Then do the same for the tag file associated with your language, like '"C" Compiler Configuration Tag Files'

We're looking into building a mechanism that automatically configures this for you.

You can get more information about tuning SlickEdit in the v14 User Guide, there's a new section called "Performance Tuning". It's available online if you are on an earlier version and most of the information applies.

You can also get more info on our Customer Forums:

Anonymous said...

Thanks Scott!!! your tips did it, i was thinking of how to not use VisualSlick edit because this problem was really bad. I have used VS for many years and love it. I have googled over and over and finally found this today. Thanks i am whole once again.