Thank you for responding.
I'm very sorry for your problem. We take all problem reports seriously, and performance issues are one of our top priorities. Much of what we did in v16 was to improve performance. Despite your experience, v16 is faster at tagging for most people. I don't know why it has been so bad for you.
Please remember that the forums are not an official support channel. See: http://community.slickedit.com/index.php?topic=28.0.
Although our staff will monitor the forums and answer selected questions, it is not our intent to address support requests from within the forum. Support requests should be submitted via www.slickedit.com/supportcase
The forums are for users to help users. We answer items when we can, particularly if they are helpful to other users. But all support issues should be routed through official support channels. I probably confuse things by posting to so many of these. If so, I apologize for creating this confusion.
Right. I guess I just assume you'd be better off if solutions are public. Stuff done through the support channel means you guys have to spend time with each person even if their solution could be public.
Can you post a case number so I can look into this one?
I'll open a case if these don't solve the issue.
Some questions (ignore any questions already covered in the support case):
1) It sounds like you're using background tagging. If so, turn it off. Tools > Options then Editing > Context Tagging. Set "Number of tagging threads" to 0 and the two "Use background thread to..." items to False. Of course, this means you won't be able to do anything until tagging has finished, but it sounds like that's where you are now. However, foreground tagging may avoid the problem that is causing this to be so slow, so it may shorten the time before you can start working. What were your tag times like using v15? Please let us know the difference in time to tag with background tagging on and off.
I'll try that and tell you how it goes
2) Are your source files stored locally?
Yes
3) Are your project and workspace files stored locally?
Yes
4) How many files in your workspace/projects? What language?
40k-50k files, mostly C++. I'm only adding .c, cc, .cpp, .h and .py files to my project. I've sent links to the source before is the project is open source.
5) Was this a problem using v15? If not, can you use v15 while we are trying to get to the bottom of this? Are there specific changes in v16 that you need? Obviously the multithreading work wasn't a boon for you.
Speed has been a problem on all platforms for this project. Wait times of 7 minutes or more were common on Windows each time I synced (which rebuilds the .vcproj files in my project)
A big difference is a new workflow using git. A workflow that is gaining massive traction.
If you are not aware of how git works, Git supports branching in a way that no other version control system does so in git it is most common to switch branches often (several times an hour). When you switch branches in git it changes a bunch of hardlinks on your files (similar to how OSX Time Machine works if you are familar with that). So in other words. 'git checkout feature1' will nearly instantly switch all the files in your project to the versions you were at when you started working on feature1. 'git checkout feature2' will switch them all to the state needed for feature2. It generally takes git like 0-2 seconds even for 50k files.
What this means for slickedit is that several thousand files in a project might change underneath it several times an hour.
git usage is taking off. Tons of projects are moving to github. Chrome is moving to git. Webkit is moving to git. Processing is on git to name a few.
The point I'm trying to make is slickedit is going to have to work well with this new and increasingly popular workflow and I'm guessing it wasn't really designed with that in mind. When I was using svn or p4 or cvs, files didn't change often. Generally if I worked in multiple things at once I had separate copies of the repo and switched that way. In that old style workflow I'd switch projects to work on a different feature. c:\work\repo_feature1\project.vsj vs c:\work\repo_feature2\project.vsj. The files in each were relatively stable. In git though I'm always in c:\work\repo. When I want to work on feature 1 I type 'git checkout feature1' and the files in c:\work\repo magically change to the state needed for feature 1. When I want to work on feature 2 I type 'git checkout feature2' and again the files all magically change back to the state needed for feature 2.
That means slickedit is now noticing all these files changed and starts tagging. That 7 minute wait in Windows which only happened each time I synced a particular repo now happens several times an hour and tagging being slower on linux makes it even worse. I can switch tagging off but I rely on tagging. Even if I make it not tag in the background the git workflow means the long wait comes up really often.
If you can find the source of the poor performance of tagging in linux and find out why while it is tagging the editor's response is so slow that would probably be the biggest help.
6) Can you post your Help > About SlickEdit info (redact anything you don't wish to share)?
SlickEdit 2011 (v16.0.0.6 64-bit)
Serial number: xxxxxxx
Licensed number of users: Single user
License file: /usr/local/google/gman/slickedit/16.0.0.6/bin/slickedit.lic
Build Date: May 05, 2011
Emulation: Brief
OS: Linux
OS Version: Ubuntu 10.04.1 LTS
Kernel Level: 2.6.32-gg465-generic
Build Version: #gg465-Ubuntu SMP Mon Apr 11 05:52:28 PDT 2011
Processor Architecture: x86_64
X Server Vendor: The X.Org Foundation
Memory: 47% Load, 4880MB/10178MB Virtual
Shell Info: /usr/local/google/gman/slickedit/16.0.0.6/bin/secsh -i
Screen Size: 2240 x 1600, 2240 x 1600
Project Type: Gnuc
Language: .cc (C/C++)
Installation Directory: /usr/local/google/gman/slickedit/16.0.0.6/
Configuration Directory: /usr/local/google/gman/.slickedit/16.0.0/
Hotfixes:
/usr/local/google/gman/.slickedit/16.0.0/hotfixes/hotfix_se1600_1_cumulative.zip (Revision: 1)
That's all I can think of for now. We may not be able to fix this until the v16.0.1 release, which is planned for late July. But we'll do our best to get to the bottom of this and send you a fix if possible.
One thing I did notice, the configuration path was on the network. (~/.slickedit). I've moved it to be to be local. I'll see how much that helps.
Thank you. I'm sorry for being frustrated. I'm one of your biggest fans. I've gotten others here to use slickedit and I'm also one who realizes the value in paying for something even when inferior but free alternatives exist.