Sublime text 2 is freezing from time to time, when I have many selections in large files. After a while it continues. I am on windows 2008.
For example it happens when I hit ctrl-d many times or even keep it pressed to add many selections. It adds selections, then stops, and after a while continues adding selections.
I suspect this is due to garbage collection.
Is there a way to avoid this or make the freeze period shorter? Maybe give it more memory, or even better less memory so gc is more frequent but much shorter.
Or maybe this is some sort of swapping or missing or wrong temp file config.
What is the reason and is there a good solution for it?
Sublime Text 3 may freeze too. Plugins can cause that.
First thing
...you may want to do is run command CTRL + SHIFT + P -> Plugin Development: Profile Events. You will get a list of events which different plugins are listening to and time it taken for them to process the event.
Give special attention to on_modified event. Quote from sublime docs:
Expensive operations in event listeners can cause Sublime Text to
become unresponsive, especially in events triggered frequently, like
on_modified() and on_selection_modified(). Be careful of how much work
is done in these and don’t implement events you don’t need, even if
they just pass.
This was my case: a plugin was meticulously processing every on_modified event which resulted in overflowing the thread queue and freezing ST.
Also
... don't forget that Sublime Text has a console where you sometimes can find useful messages and tracebacks. To reveal console use a key binding CTRL+`. Working for a while with your eye on the console may help you get the idea if something is going on wrong.
It recently starting freezing for me too, each time I'd re-focus on code in a Sublime window, whether that be alt-tabbing or even searching the command palette!
What fixed it up quickly for me was Reverting to a Freshly Installed State, then restoring those folders.
Update: It turned out to be Git Conflict Resolver
, perfectly responsive after disabling.
This question is old, and the issue did not occur with later versions anymore.
So I suspect it was fixed at some point.
If you still experience freezing in sublime text try the following:
Find out what version you are running and try switching to the latest stable version.
See if the freezing could be an operating system issue. This could be indicated by not only sublime text but at the same time all other applications freezing.
If you have a different solution or explanation why not add it here for reference.
I still believe the underlying reason could have been a garbage colletion (read at wikipedia about garbage collection) within the application.
Related
I have made this AutoHotKey script after reading the manual, searching and troubleshooting for endless hours in the last few weeks:
#Persistent
#SingleInstance force
if A_Args[1] > 0
{
Menu, Tray, Icon, C:\blablabla\new notifications.png
}
else
{
Menu, Tray, Icon, C:\blablabla\no new notifications.png
}
This, I have compiled into test.exe. Then I call it like this from a terminal: test.exe 1, test.exe 0, test.exe 2, test.exe 3, etc.
If I do it slowly/manually, it works: it only ever keeps one instance of the script, showing visually as a nice little icon in the Notification area (as intended), never launching multiple instances.
However, when I started actually using it for real, by calling the same terminal command from my scripts, it often opens two or more instances, which are kept open and just make the Notification area longer and longer, ignoring the rule that it only can run as one instance ever.
I was able to "solve" it by introducing a short "sleep" in my script after each such command call, so that the same script never calls it too quickly in succession. However, today, I realized that multiple different scripts of mine often call it at the same time, or nearly at the same time. This means that my "clever" solution of sleeping falls short.
I then thought that I can use the database to keep track of when the last time a script called this, and don't do it if it's too soon, but if I did that, the whole point would be lost since I can no longer trust the icon to accurately tell me whether or not there are new notifications in my system. I'd constantly be wondering if there had been such a "race condition" and manually go and check anyway, defeating the point of this visual indication which is supposed to let me always know "at a glance" whether or not there are new notifications in my system.
Maybe I could have a loop in my scripts and repeatedly re-try if it detects that a notification has been sent too recently, but that means my scripts will potentially stall for a long time as they all send notifications (especially in the morning, when I wake up and kickstart my system). It just seems like the wrong solution.
Is there really no way to properly handle this in the script itself? As is obvious from my description, the #Persistent and #SingleInstance force rules aren't respected.
(I've had similar problems in the past with programs being unable to "handle" running commands too quickly, and I never know what to do about it except to introduce sleep. But even then, it often glitches out. For example, Notepad++ requires me to first open a document and then open it again with a specified line number, sleeping in between, or else it doesn't go to the specified line.)
I use Qt's wheelEvent to implement scrolling in a custom widget. Normally, this works fine.
However, when dragging the mouse and scrolling with the mouse wheel at the same time, it sometimes happens that rotating the mouse wheel by one step does not do anything at first (no wheelEvent is received). This might even randomly happen a few times successively. The next time the application does receive a wheelEvent, it comes with an accumulated event->angleDelta() of all previous events that were not reported separately. Apparently the events are buffered together in this case. Note that the wheelEvent may happen a long time after the initial mouse wheel rotation(s) in this case: it only happens once the wheel is rotated again.
This is an issue, since it means that my widget sometimes does not properly react to scrolling. Is there any way to avoid this kind of buffering and receive all wheel events immediately instead?
Notably this behavior is only well reproducible if at the same time dragging the mouse within the widget, which performs some non-trivial actions as a result. So I suspect it might happen if the event loop seems busy. But it certainly isn't busy enough to be unable to handle each wheelEvent. So I would like to disable this buffering.
I observe this on Linux with Qt 5.12.0. Any help is appreciated, thanks.
I am answering my own question here since I found the answer after writing it (but was unable to google it before).
The same problem has been reported here (with a somewhat non-descriptive title): Qt QOpenGLWidget wheelEvent strange behaviour
For me, setting Qt::AA_CompressHighFrequencyEvents (see https://doc.qt.io/qt-5/qt.html#ApplicationAttribute-enum) to false seems to have fixed the issue, as posted by #gatis paeglis as an answer to that question.
I have a large data acquisition and control program written in Python3.4.2 using GUI mostly developed on Glade 3.18.3, Gtk3.0 GObject running Debian 8 with XFCE.
There are timers that keep doing things, and these work fine. After startup, the program runs for some 3 - 7 days, then suddenly, all of the windows go blank and stay blank. Other applications are not affected. Memory and CPU usage is modest.
There are no indications of problems prior to the windows going blank. The windows show their title bars and respond normally to minimize, restore, move to another Workspace, etc. It looks like they are not getting repainted - no widgets are visible at all. The code is way too large to post here, and I am not able to isolate a specific problem area for lack of obvious symptoms other than the blank screens. There are no error messages or warnings.
The timers continue to run, acquire data and control things. This happens whether the program is run from the command line or under PyDev in Eclipse.
Things I have tried:
In the main timer loop, I put code to look for a file, and then exec the command in it, printing the results, so I have been able to mess with the program in real time:
Replace the usual Gtk.main() with a while loop whose variable, if not made false, will re-execute the Gtk.main(). Executing Gtk.main.quit() stops Gtk.main and starts it again. Windows still blank. Did this repeatedly to no avail.
Experimented with garbage collection with GC. Collecting garbage makes no different. Windows still blank.
Put in code to print percent of time consumed by the timer loops. Fairly steady around 18 - 20% of available CPU time, so nothing is hogging the CPU preventing re-paint.
I have a button that clears a label. I read the label, then executed a builder.get_object(...).activate command to the button. I re-read the label and it was now properly blank. So events and widgets appear to be working normally, at least to some extent.
Finally, if I click on the close X on the title bar, XFCE asks me if I want to wait or close now. So it seems as though there may be a disconnection or problem with signals and the OS, even though XXX.activate() works.
Web searching is in vain. Does anybody have ideas of what might be happening, useful diagnostics, or other suggestions? Many thanks!
April 27, 2017 Update:
I have taken two substantial steps to mostly work around problems. First, partly in response to a couple of Gtk crashes over the last few months, instead of ending the main program with:
Gtk.main()
I end with:
while wannalive:
try:
Gtk.main()
except:
pass
wannalive is True until user does a quit, so recovery is instant.
Second, I grouped all of the code for each window setup and initial population of static items into two functions. I also made another function for closing a window. These functions propagate to children, grandchildren windows. A function in the top window first, closes, then re-creates all windows, with one call. In operation, there are overlaps in what windows exist, but that is not a problem.
Above, I describe that I can inject code with an external program. The external program has a button that injects a call to that third function. In about five seconds or less, the result of a single button click is to replace all blank windows with functional windows. For my purposes in a controlled environment with a trained operator, this is acceptable.
Next, let me address the relationship between the timer loops and GUI events processing. I do use GObject.timeout_add(ms, somefunction). Experiment shows that a button that calls time.sleep(5) stalls the timer. Experiment shows that injecting time.sleep(5) in the timer loop stalls the GUI. This is consistent with my belief (correct me if I am wrong) that Python runs on a single thread. Therefore, bad code caught in an infinite loop should stall both the GUI and the timer loop. (The program has one timeout_add call.)
Recently I am using clang_complete to do C++ code completion. It is good and fast for small program but too slow for my case (I am working on large code base and usually one file takes several seconds to compile), even if I used libclang, which can cache some parsed results to speedup later parsing, if I understand correctly.
Currently clang_complete will block in ClangComplete until libclang finishes parsing. Even though it starts a worker thread, main thread still repeatedly checks if user pressed CTRLC or the worker thread completes successfully. During this period, vim becomes irresponsive and thus makes this plugin hard to use.
I want to make some improvement to this behavior, for example, ClangComplete will not block, but return empty results if it takes longer than 0.2 seconds, while the thread is still running. When libclang finishes its parsing, and it detects that I am still typing the same completion word, it will popup a completion menu.
The difficulties for this is:
how to popup a menu at that time, without causing some subtle race conditions between different threads,
how does it know whether I am still typing the same completion word? I think vim itself keep track of this, because when I type something wrong, for example, std::strang instead of std::string, then I type backspace to delete the wrong ang, the completion menu will show up again. So how do I access to this internal flag?
Vimscript is single-threaded; you won't have to worry about races.
Vim will pass the base (i.e. the part of the completion word already typed / completed) into your function. Check out :help complete-functions for details and an example.
In general, your approach (assuming you're using an embedded language like Python or Perl for the multi-threading) should be feasible; however, I haven't seen something like that attempted yet.
Can anyone give me a scenario where they think busy cursors are justified? I feel like they're always a bad idea from a user's perspective. Clarification: by busy cursors, I mean when the user can no longer interact with the application, they can only move their hourglass mouse pointer around and whistle a tune.
In summary, I think that the user should be blocked from doing stuff in your app only when the wait interval is very short (2 seconds or less) and the cognitive overhead of doing multi-threading is likely to result in a less stable app. For more detail, see below.
For an operation lasting less than 0.1 second, you don't usually need to go asynchronous or even show an hourglass.
For an operation lasting between 0.1 and 2 seconds, you usually don't need to go asynchronous. Just switch the cursor to the hourglass, then do the work inline. The visual cue is enough to keep the end-user happy.
If the end-user initiates an operation that is going to take just a couple of seconds, he's in a "focused" mode of thinking in which he's subconsciously waiting for the results of his action, and he hasn’t switched his conscious brain out of that particular focus. So blocking the UI - with a visual indicator that this has happened - is perfectly acceptable for such a short period of time.
For an operation lasting more than 2 seconds, you should usually go asynchronous. But even then, you should provide some sort of progress indicator. People find it difficult to concentrate in the absence of stimulation, and 2 seconds is long enough that the end-user is naturally going to move from conscious ‘focused’ activity to conscious ‘waiting’ activity.
The progress indicator gives them something to occupy them while they are in that waiting mode, and also gives the means of determining when they are going to switch back into their ‘focused’ context. The visual cues give the brain something around which to structure those context switches, without demanding too much conscious thought.
Where it gets messy is where you have an operation that usually completes in X time, but occasionally takes Y, where Y is much greater than X. This can happen for remote actions such as reaching across a network. That's when you might need a combination of the above actions. For example, consider displaying an egg-timer for the first 2 seconds and only then bringing in your progress indicator. This avoids wrenching the end-user from the 'focused' context directly to the 'waiting' context without an intermediate step.
It's not specifically the busy cursor that is important, but it IS important, absolutely, always to give feedback to the user that something is happening in response to their input. It is important to realize that without a busy cursor, progress bar, throbber, flashing button, swirling baton, dancing clown.. it doesn't matter ANYTHING- if you don't have it, and the computer just sits there doing nothing, the computer looks broken to the user.
immediate feedback for every user action is incredibly important.
I think you may well be right: in a decent asynchronous app, you never need to show a busy cursor. The user can always do something even if the big last operation is completing.
That said, sometimes Java apps like Netbeans or Eclipse, or even Visual Studio, hang with no busy cursor and no hope. But in that case, a busy cursor probably wouldn't help much either...but I think you're right: busy cursors are from a non-multithreading era for apps. In Flex apps, for instance, EVERYTHING is automatically event-driven callbacks, so setting a busy cursor would just be meaningless (though possible, of course).
You show a busy cursor when the user can not do anything until the operation is completed - including exiting the application.
I find it interesting that you don't see busy cursors in Web Browsers - perhaps that why people like them so much.
No, wait, I have a better answer. You show a busy cursor when the computer is thinking.
When one hits the Refresh button on a web browser, busy cursor must appear immediately to tell the user to let them know that a page is being loaded.
I think it was Don't Make Me Think that said that the tolerable loading time for human is zero second.
Google says:
Responsive
It's possible to write code that wins
every performance test in the world,
but that still sends users in a fiery
rage when they try to use it. These
are the applications that aren't
responsive enough — the ones that feel
sluggish, hang or freeze for
significant periods, or take too long
to process input.
There are two purposes for it:
Indicate for the user that something is happening.
Indicate for the user that nothing can't be done right now.
Busy cursor is better signal about the operation than nothing. For longer lasting operations something better should be used. For example browsers is still operational when a page is being retrieved and there is even a button to stop the operation. As the user interface is fully functional, there is no need to use busy cursor. However busy cursor can be used even in this kind of situations in the transition phases like when starting the operation or when stopping it.
I try to use them on any action that may take from 0.5 to 3 seconds, for longer actions I think progress indicators with enough information should be used.
I noticed with Fedora 8 at least that when an app sets the "busy" cursor, the "busy interactive" one is actually displayed. I guess this is because the system is still responsive to mouse input (like dragging the window etc.). As an aside, selecting the "busy interactive" cursor explicitly on linux is tricky:
http://www.pixelbeat.org/programming/x_cursors/
The only thing I believe the busy cursor does is it informs the user that ...
I'm not outright ignoring you, I'm just doing something else that may take awhile
While it is absolutely necessary to alert the user that your application is doing something, a busy cursor is only useful for the first few seconds of processing. For a delay of more than about 15-20 seconds, something else must be presented such as a progress bar, status message, message box, whatever. People assume your software has locked up after a minute or so and will try to terminate it. Sometimes, overall visual cues are just as important as a busy cursor.
For example, applications with tabs that do not respond with appropriate highlighting until the operation in the tab completes can be fixed up by updating the tab temporarily until all operations are complete. Sometimes, just a little optimization or refactoring will clean up horrible user interface responsiveness such as this.
I would use them only for quick completing things, like say under half a second. If anything takes longer than that then a progress dialog should popup, or a progress bar should appear in the status bar or somewhere else in the interface.
The user should always be able to cancel the action if it is taking too long to complete.
In response to the comment, the busy cursor would only be visible for the half second or so, as once the progress dialog is up it should change to being one of those "half busy" cursors, or just the normal arrow cursor.
You should avoid having a busy cursor up except in extreme circumstances, and if you think you need one, then think again and redesign.
For example, to indicate that you've clicked on a button, even though it's not done processing the event. If there were not some indication, the user might try to click the button again, causing all manner of badness.