SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: lahughes on May 13, 2019, 08:17:10 PM
-
Help Please! Slickedit is basically unusable.
I just downloaded Linux version of Slickedit. I am a long time (but not power) user of Slickedit. I created a C++ project and added my source tree. I opened up several files and when I am scrolling through them the window will grey out and is unresponsive.
My terminal shows many of the following messages:
QVariantMap DBusMenuExporterDBus::getProperties(int, const QStringList&) const: Condition failed: action
SlickEdit Pro 2018 (v23.0.1.2 64-bit)
OS: Linux
OS Version: Ubuntu 16.04.6 LTS
Kernel Level: 4.15.0-48-generic
Build Version: #51~16.04.1-Ubuntu SMP Fri Apr 5 12:01:12 UTC 2019
Processor Architecture: x86_64
X Server Vendor: The X.Org Foundation
Memory: 23% Load, 6650MB/28625MB Virtual
Shell Information: /home/lahughes/slickedit-pro2018/bin/secsh -i
Screen Size: 2560 x 1440
Project Type: Gnuc
Language: .cpp (C/C++)
Encoding: Automatic
Hotfixes:
/home/lahughes/.slickedit/23.0.1/hotfixes/hotfix_se2301_4_cumulative.zip (Revision: 4)
I disabled the minimap which didn't help. There is no message indicating what it might be doing.
Thanks for any ideas.
-
I don't know of any known problems that do anything like that. Probably the fastest way to narrow it down is take a Slick-C profile.
Start up SlickEdit. Go to the Macro -> Slick C Profiler -> Begin Profiling to start the profiling. Scroll around in one of the files you're seeing delays in for a couple of minutes. Then select Macro -> Slick C Profiler -> Finish Profiling to stop the profiling. And then select Macro -> Slick C Profiler -> Save... to save the profile.tsv file, and attach that to the forum post, and we'll take a look at it.
The terminal messages have something to do with the menu integration with the top menu bar in Ubuntu, but I've not seen those before, so not sure if it's significant yet. If we want to rule out a problem there, you can start SlickEdit with the QT_X11_NO_NATIVE_MENUBAR environment variable set to 1, and see if that makes any difference.
-
@lahughes The email address you registered with is not valid. You will not receive notifications of replies to your posts until you correct it.
++rodney
-
I'm not sure why my email isn't valid - I updated it a couple days ago. I'll double check it.
It took awhile this time for the screen to blank out. It just did and I stopped the profiler and saved the file as directed. I've attached it. Thanks for looking at this!
-
I forgot to update the forum and had only updated slickedit.com
-
Out of curiosity, about how long was the profiler running? Was that just scrolling trying to reproduce the problem, or some editing as well?
Do you have symbol coloring enabled?
-
I didn't enable it explicitly - so it's whatever the default for C/C++ is.
-
Maybe you should capture a few more and see if there is anything in common?
BTW, Patrick also asked
Out of curiosity, about how long was the profiler running? Was that just scrolling trying to reproduce the problem, or some editing as well?
-
Also, what changed? i.e. have you used slickedit on this version of Ubuntu before?
Are you using a brand new configuration folder or is it one you've used for a while. If it's not brand new, try a new one with vs.exe +new -sc some-new-empty-folder.
-
I've not used the linux version before. The entire setup is new to me. Brand new configuration, fresh SE download, fresh Ubuntu 16.4 install.
-
About how long was the profiler running? Was that just scrolling trying to reproduce the problem, or some editing as well?
It looks like there were a lot of tagging lookups, which I wouldn't expect for scrolling unless symbol coloring is on. Which is why I was wondering if there was editing being done during the profiling too. If you want to double check and see if symbol coloring is off, go to Document -> C/C++ Options -> View and see if the "Symbol coloring" checkbox is checked.
-
The profiler ran some of the afternoon, overnight, and next morning. I did do some editing. Symbol coloring is not selected.
Thanks
-
Ok, that explains what I see in the profile. The profile groups things by overall times, so editing functions take up most of the time, and whatever the scrolling contribution was, it was swamped by the noise, and doesn't really stand out.
To attack it from the other end, have you run with the QT_X11_NO_NATIVE_MENUBAR environment variable set to see if that makes scrolling hitches go away? It should certainly make the terminal messages go away, but I'm not sure if it's related to the performance problem?
I need to run that version of SlickEdit on a Ubuntu 16.04 and see if I can at least reproduce the messages and see what's causing those.
-
I ran yesterday with the QT_X11_NO_NATIVE_MENUBAR set and did not see any of the messages to the terminal. It grayed out/stopped responding twice that I recall.
-
If this was more predictable, I'd be able to have you use something like strace to get a better idea of what was going on when the slowdown occurs. I haven't reproduced anything with Ubuntu 16.04 so far.
I'd say keep running with that environment variable set for now, just to keep things simple.
So does it seem random to you? Never the same file? Or only big files, or the file size doesn't seem to matter? Are your source files on a network share? Hmm, if you look in your system logs on that linux box, is there anything out of the ordinary logged around the time you had the slowdowns?
-
It does seem random to me, but always when I am scrolling (and have someone looking over my shoulder :). I am only working in one file and haven't noticed it while looking through other files. This file isn't that large. My source is local. I'll look at the logs the next time it does it since I didn't catch the time(s) it happened.
-
Ok, in the meantime, if you could post your user.cfg.xml file from the config directory ($HOME/.slickedit/23.0.1/user.cfg.xml), I can take a look at it and see if I can get anything out of it that can help.
-
Here you go.
-
When you get a chance, open that file you have problems with, go to the View -> Symbol Coloring menu, and see if the "Enable Symbol coloring" entry is checked. If so uncheck it. I suspect that it got turned on just for this file, and is what's making us pause. Symbol coloring does a lot of tagging lookups for what's on the screen to give more specific colors for the source code than just "keyword", "library function", etc... A limitation of symbol coloring is that if the tagging queries take too long, it can block the main GUI thread.
I should have caught on to this sooner, but I didn't know how much of the profile to trust (it ran long enough where some of the counters overflowed), and I forgot symbol coloring can be enabled per-file in addition to at the language level.
-
Enable Symbol coloring does not appear to be selected.
-
And it was not enabled for any languages in your config. There shouldn't be a way for those lookups to happen otherwise, but I'll check the code and see if I find anything. It's the only thing I've spotted so far that can block the main thread. Thanks.
-
I've not used the linux version before. The entire setup is new to me. Brand new configuration, fresh SE download, fresh Ubuntu 16.4 install.
This could be a QT / Linux problem. Google for the following gets a few hits
QVariantMap DBusMenuExporterDBus::getProperties(int, const QStringList&) const: Condition failed: action
-
Should I try to get the macro going again? Today seems to be day when it is graying out frequently.
I looked up QT (I am unfamiliar with it) and it is supported on Ubuntu 16.04.
-
If you think you can capture the profile in a relatively short amount of time, then go ahead. If you get it to happen with the profiling, post it and let me know roughly how long it was running.
The Qt thing with the messages is something I need to look at, but I think is separate from the pausing, since turning off the system menu integration doesn't change the delays you're seeing.
-
Actually, one more thing. Can you post the vrestore.slk file from your configuration directory? (Unless you're overriding it at the command line, that would be $HOME/.slickedit/23.0.1/vrestore.slk).
-
Here you go. It ran for about 5 minutes before graying out. It was unusable for about 5 minutes before coming back. I've attached the output from the macro as well as the vrestore.slk file.
-
Had you just done a references search before it grayed out, or you were just moving through the file when it happened?
At first glance, it's largely tagging lookups. The large amount of time and the fact that it's blocking the gui thread are strange. I think we've already gotten the usual information we'd usually collect for something like this. You have a few files that are local to your system and not on a network drive. It happens in just one of the files, and you said the file isn't that large.
I still have some things to look at here. We may be able to use the linux "perf" command to get a profile of what's going on at a lower, native level when it hangs up like that. I'll update the thread with instructions if it comes to that.
-
Going over it again and talking to the tagging developer, it looks like a background reference search is running into some files that are taking it long enough where it ends up delaying the main thread. Why that happens depends on what the Ctrl-/ search is for, and what's in the files it's having trouble with.
If you can figure out what search causes the slowdown, then you can see what files it's having problems with by watching the status messages in the lower left hand corner. There will be messages like: 'Searching "somefile" for references. Press any key to stop.' Make a note of any files that take a long time.
If you're not using a lot of the reference results, you could also change "Tools -> Options -> Editing -> Context Tagging -> Find references search strategy" to "incremental". That defers processing until you ask for the next reference.
The worst case I can get on my system is doing a reference search for 'const', which takes about 5 seconds each for a handful of Qt header files in my workspace. They aren't big files, but are structured in a way that makes the the tagging jump through hoops to make sure it's searching the right context. Usually I'd use "find in files" to search for the keyword 'const', and only use a reference search if I wanted to find "operator const()" functions.
-
I set the search option you asked for and I'll update the thread whether that helps or not.
This is happening in a different file as well. I don't recall if I did reference or not, but I don't think I did. There are no messages displayed in the lower left hand corner.
All the code is local to my machine.
-
Even after setting the search option it is still graying out. I moved my code to a different directory, cleared the files and pointed to the new directory. It's grayed out twice now in the last 20 minutes.
-
Go to Tools > Options... > Editing > Context Tagging(R)
* Verify that you have "Updated references and call tree on single click" turned off (this is off by default).
* Try the "Find references search strategy" of "Find all references immediately"
If you are absolutely certain that you do not have any References activity going on in the background, then I think you should collect a new profiling run, because the previous one was obviously heavily weighted by a references search you did.
Another thing to try is to close the "Preview" tool window, it can generate some work since it has to load files and extract and format comments. There are Context Tagging options to make the Preview tool window wait longer before updating.
You pointed out that all your source code is on a local drive. Is your home directory on a local drive or a shared network drive?
Finally, when you say scrolling, do you mean scrolling in the traditional sense, or cursor/page up/down through the file?
-
. * Verify that you have "Updated references and call tree on single click" turned off (this is off by default).
It was set to the default of off
* Try the "Find references search strategy" of "Find all references immediately"
Changed back to "Find all references immediately". A previous response had me change it to "Find references incrementally"
If you are absolutely certain that you do not have any References activity going on in the background
Other than the lower hand status bar indicating what is going on (there was nothing in the status bar) I don't know how else to be "absolutely certain".
My home directory is a local drive. I've started a new profiler log but I do need to get work done so I can't guarantee there won't be other stuff in there.
When I say scrolling - I mean that I am using the wheel on my trackball mouse and sometimes grabbing the scrollbar handle and dragging it down. Also - I should note that I usually have the "References" tool window showing - rarely do I use the "Preview" tool window.
-
I've attached a new profile. There are two gray outs in it - both between approx 1:20 and 1:50 MST. I did not do any editing and I may have done some referencing. There was no message in the status bar while it was gray.
-
You are getting a massive number of _mouse_move() messages. I don't know if this is unique to the trackball. I'm going to research the code we are using there a bit more. I think there are some opportunities for optimzation.
For the time being, I would recommend turning off the following option:
Document > C/C++ Options... > Context Tagging(R) > Show info for symbol under mouse
-
I appreciate all the help here!
If I turn off the option does that mean that I can't hover over a variable and get info for it? (it appears so) If so that's unfortunate as I use that a lot.
I'll update the thread in a bit with status.
-
I've used it for a couple of days and so far so good. Is there any news on a possible fix?
-
There will be a fix in 23.0.2. Of course, I don't have your hardware or your code, so I can't really reproduce whether it is going to be fixed entirely in your case, but in theory, the changes I made should cut back the amount of work being done significantly.
-
I'm happy to try out any fixes. I ran into the gray out again. At the time I was finding all references to a method. I did that several times before it finally went to lunch for a bit.
-
I'm adding another profiler output. This one didn't have any mouse/wheel action going on (as far as I'm aware). This was a new project that I did a search for all references of a class::unlock() and there are plenty of classes (unrelated) that have an unlock() method.
-
Let me ask, since you did not address it. Is the new profiling run from 23.0.2 ?
-
No. I went looking for the new update but it isn't available to me yet. At least I look under hotfixes, updates, and upgrades.
SlickEdit Pro 2018 (v23.0.1.2 64-bit)
Serial number: VLX931365
Licensed number of users: Single user
License file: /home/lahughes/slickedit-pro2018/bin/slickedit.lic
-
Please download and install 23.0.2
https://www.slickedit.com/trial/slickedit (https://www.slickedit.com/trial/slickedit)
There are some changes that will hopefully improve the performance.
-
I downloaded this version and it still grays out. It's not better or worse.
I've attached a profile that had these actions:
Selected a function that was just in this file and selected 'Go To References' - No gray out.
Moved to the 'Defs' tab, mouse scrolled until I found a method that I knew was in multiple files, double clicked method name, right clicked on method name in window and selected 'Go To References' - grayed out 11 times before I was able to cancel and it returned with control.
No messages in the status bar. From 'top' it is pegging my CPU, using only 3.1% memory
-
The set of profiling results shows there is something really ugly going on. There are far too many calls to match_brackets() and match_generic() happening, so I suspect that there is preprocessing in the code that is not being expanded correctly leaving behind what is likely to be mismatched brackets in the source code.
Is it possible for you to share that code with us so that we can work on this problem? If you can narrow it down to just a few files, then you wouldn't have to share the entire project.
The best way to do this would be to look at the locations where the name of the function you were doing references on appears (use a regular Find in Files, exact case, whole word, to do this) and try a push-tag from each of those locations, you might be able to pinpoint an instance that exhibits the performance problem. If you do you can run a command like "codehelp-trace-push-tag" to get a trace of what Context Tagging is trying to do in that case. (The trace will go to SlickEdit's debug window, you can cut it to the clipboard by clicking in the debug window and hitting Ctrl+X).
I know this sounds tedious, but there is no other way for us to get a reproducible case at this point.
-
Thanks - I will work on that. However - I did a SE help on push-tag and what came up is tag_push and bookmarks. Can you send me more details on how to do this? (I am not a power user of SE as I do embedded software ;).
I believe I can narrow it down to two files - if so I can send those but I cannot send all of it.
-
You would run "codehelp-trace-push-tag" from the SlickEdit command line (click in the message bar at the bottom and then type the command.) There is no help on this command, it is an undocumented command strictly for debugging context tagging.
-
Do I run the "codehelp-trace-push-tag" before I select the 'find all references' on the method that causes it to lock up? or after? I have no access to the command line while it's grayed out.
-
Follow these steps:
1) Search > Find In Files...
a) Search for: (the identifier name of the function that caused the problem when you did references)
b) Look in: <Workspace>
c) File types: All Files (*)
d) Match case: checked
e) Match whole word: checked
f) Match color: unchecked
g) Click on "Find"
2) Navigate through the search results and hit Ctrl+Dot to try to do a push-tag. Basically alternate between Find-Next (Ctrl+g) and Push-tag (Ctrl+.) until you hit a case that seems really slow. (keyboard shortcuts may vary based on your emulation, you can figure these out).
3) When you find a case that is really slow (note that it might not actually be a reference to the original function, it might be some other function with the same name in another class). Then put the cursor on back on that symbol, click the mouse in the message bar to reveal the SlickEdit Command line, then type the command "codehelp-trace-push-tag" and hit enter.
4) The trace will go to the SlickEdit debug window which should show up. Click on that window and then hit Ctrl+X to cut it's contents to the clipboard. Then paste that to a plain text file and post it here.
The location of the slow push-tag might help you narrow down where things are going wrong in order to trim things down to just a few files.
-
Your steps showed me the problem. The issue is that our repository has a bunch of binary (for lack of a better word) files. In our case *.i, and *.d. These files had strings that were the method I was searching for. In this case ".Unlock(". When ^g from one file to the next, after leaving one of these ".i" files it hung. I was never able to get it back so I killed 'vs.exe'.
I removed all the files from the workspace and when I added the tree I excluded all *.i and *.d files. I no longer have it hanging. So far.
I've not been able to reproduce this with a smaller project with just those files.
-
Awesome. I'm glad you found a solution. It's definitely possible for a binary file named .i (preprocessed C) or .d (D language) to really give tagging problems.