Menus are slow to show up

[RonG]

I am new to SE, just coming over from SourceInsight, and am bothered by the slow response (about 1 second) it takes for a menu to show up when on click on the top line (File, Edit, Search, ...).  Is this something that is settable?

Basically, what happens is:

 - highlight the top-level menu item (i.e. File)
 - background changes
 - click menu item
 - 1 second later, menu shows up (not a problem on any other app)

Running WinXP-SP2.  Any thoughts?

[srouleau]

I've had this problem as well for quite some time.

At the beginning of this week I finally decided to come and report this, started a reply to this message, went back to Slick to triple-check that, yes indeed, the Window menu was slow to appear, only to see that, no, it wasn't anymore.

So I cancelled my post.  But hey, it's back again this morning.  I have 5 buffers opened, and pressing Alt-W gives me a definite lag.  It's a bit of a pain, since over the years I got used to toggling between buffers using Alt-W,2  Alt-W,3 and so forth.  I know there are other keyboard shortcuts, but old habits die hard.

It appears to affect every menu.  I tried disabling the menu effects in WinXP, didn't change a thing.

Steph

[ScottW, VP of Dev]

Weird. I've never seen that problem. I run WinXP SP2 on a P4 2.2GHz machine and my menus pop instantaneously. I've got 1 GB of RAM. I consider this to be a pretty good test machine because it's not terribly fast.

What CPUs do you have, how much memory, is the CPU busy doing other things? Are you both on the latest version, v12.0.3?

Can you reproduce this with a default configuration? Backup the contents of your config directory, which is listed on the Help > About SlickEdit screen. Then delete the contents of that directory, the "12.0.3" directory. Start up SlickEdit and it will create a default configuration. Try to reproduce the problem. When you are finished, delete the contents of the config directory and restore your backed up version.

Final question, and this is a very important one. Is your computer close to a singularity, like a quantum black hole? If so, the time dilation it experiences could make it appear as though the menus are opening slowly when, in fact, they are opening near instantaneously. We don't specifically warn users about the dangers of working near singularities, but it is something you should bear in mind. 

--Scott

[srouleau]

Hey Scott,

I sent my answer before I read your question, and time got compressed so everything is fine.

I'm running on a WinXP 64, 8GB RAM, dual-core with HT (it's actually an engineering sample, forget which model).  I think there's enough juice to open up the menus

Oh, no.  I'm actually running 10.0.3 on this box.  No way.  I'll need to find a rock and crawl under it.

I'm in crunch mode (hence the 'goddamn menus open up NOW') and won't have to upgrade my setup to 12 until next week.  I'll let you know.

[ScottW, VP of Dev]

Nah, don't feel bad. I never had that problem on v10 either. I do wonder if running XP 64 is the issue. This is an untested configuration. I can't imagine why that would be a problem, but if it's between that or the singularity, my money is on XP 64.

I'll be curious to see if RonG is also running XP 64.

--Scott

[SlickEdit Support]

Hi RonG and srouleau,

Let's try this one from a different tack.

Do you have a large number of makefiles in your project or workspace? Or any makefiles at all?

You can go to Macro-->Set Macro Variable and set the value of def_show_makefile_target_menu to either 2 or 0. This slowdown is usually seen when you have a large number of makefiles and/or source files in your workspace and stems from the Target menu being added to the Build Menu.

1) Bring up the Set Variable dialog (Macro-->Set Macro Variable).
2) Enter def_show_makefile_target_menu in the "Variable:" field.
3) Enter 2 in the "Value:" field.
4) Hit OK.

Here are the variable's valid values just in case you want to move to the 0 level:

0 - Disable all makefile submenus (Build menu and project toolbar)
1 - Enable all makefile submenus (Default)
2 - Enable makefile submenus only in the project toolbar (Build menu makefile targets are disabled)

Hope this information helps.

Best,
SlickEdit Support

[Seaxouri]

I had this problem awhile ago. I closed down SlickEdit, renamed the My Documents\My SlickEdit Config\12.0.3 to My Documents\My SlickEdit Config\12.0.3-- and then reopened SlickEdit. This created a new, albeit reset, set of SlickEdit settings. But my menus were instantaneous again.

This happened to me going from 12.0 to 12.0.1 iirc.

Perhaps if you zipped up your Config folder and sent it to one of these developers they could reproduce it and fix it. Clearly its recreatable since so many people have seen it.

[SlickEdit Support]

Hello All,

As has been mentioned in other threads, you can copy ALL but one of the files from your old RENAMED config directory to the new config directory that was created.  (You don't need to copy any of the folders over, they will get recreated.)  The EXCEPTION is vslick.sta which is where the corruption most likely lies.  Yes, I think this is the case for you, however, RonG and srouleau may be seeing the makefile issue that shows the same symptoms.

After you have copied over all of the files, AGAIN, MINUS the vslick.sta file, many of your configuration files will restore themselves on a restart of SlickEdit.

vusrdefs.e, vusrobjs.e, and vusrmacs.e are the files that you will load manually, if they exist.  (Not everyone will have a vusrmacs.e file for example.)

With all of the files copied into the newly created directory, start SlickEdit.  Then simply enter the full path and name of the above files via the SlickEdit command line and hit Enter.  (To bring up the SlickEdit command line, hit ESC in most emulations and be sure to add double quotes around the path and file name if it contains spaces, for it to run successfully)  This will reload your most important settings that you had before.  The file of note is vusrdefs.e which contains most of your settings including fonts, colors, and key bindings.

In your case, due to the spaces, you would simply enter the path and filename(s) as such:

"C:\Documents and Settings\user_name\My Documents\My SlickEdit Config\12.0.3\vusrdefs.e"

Again, note the double quotes.  Do this with the other .e files and you should be back in business.

Regards,
SlickEdit Support

[Seaxouri]

When I saw the problem it was every single menu, not just once when I first opened up SE, or only one menu. Every menu was slow, and moving the mouse across the menu keywords would essentially lockup SE until the menu appeared... sometimes taking 15-20 seconds at each menu.

I didn't have anything with Makefiles in the menus. My settings are the same way I have been using SlickEdit for the last 12 years or so.

I hope Ron and company found a solution.

[asandler]

This problem started in SlickEdit 10. AFAIK, it happens on both Windows and Linux. It depends on project size. You can easily see this problem when number of files in the project gets above few thousands. Try creating a new project (Generic type) with whole Linux kernel source code in it and it takes 5-10 seconds for a menu to open up.

(SlickEdit V12.0.3 on Windows XP SP2, P4 3.0GHz, etc...)

[srouleau]

Hi RonG and srouleau,

Let's try this one from a different tack.

Do you have a large number of makefiles in your project or workspace? Or any makefiles at all?

0 - Disable all makefile submenus (Build menu and project toolbar)
1 - Enable all makefile submenus (Default)
2 - Enable makefile submenus only in the project toolbar (Build menu makefile targets are disabled)

Hope this information helps.

Best,
SlickEdit Support

This project has 11604 files.  I don't build through Slick, although I suppose I could.  Anyway, didn't specificy a makefile directly, but there are a bunch of jam files and other files that may have been picked up.

Setting it to '0' sure 'feels' snappier.

Still on 10.0.3 though

Steph

[ScottW, VP of Dev]

I downloaded the Linux kernel and built a new project with over 18,000 files, and I still don't see any delays with the menus. So, I don't think it's based just on the number of files. I need to try to restructure it with a number of projects and see if I can trigger this based on makefiles.

We still need help trying to figure out what is causing this problem. If anyone can create a reproducible workspace, that would be a big help.

RonG and srouleau, we haven't heard from you in a while on this thread. Did the support suggestion work for you?

[srouleau]

Scott,

As I mentionned in the post just before yours (timewarp again!) setting the macro variable removed the slowdowns in my case.  I've got it set to '0' now and everything's peachy.

Steph

[ScottW, VP of Dev]

Yeah, one of the support guys pointed that out right after I posted. Even though the execution was bad, I just wanted to make sure that we had addressed this for everyone and that there isn't some issue we still need to look into. Responsiveness is one of our highest values, and we agressively pursue those issues.

Glad things are working out for you. Do find time to get up to v12.0, though. Here are some of my favorite features from the last couple releases:
Comment Wrapping--automatically word wraps your comments as you type them.
Dynamic Surround--great new way to expand blocks and slurp in statements below.
Class Tool Window--a really neat view for the OO enthusiasts.
Enhanced Search and Replace--'nough said.
Enhanced Key Bindings Dialog--really, really enhanced.

More, more, more...

[hs2]

... and a REASONABLE performance improvement of the tagging system !
(see http://community.slickedit.com/index.php?topic=1964.msg8318#msg8318 for details)
How could you forget this point Scott
HS2