On a clean installation of Octave 3.6.4 for Windows MinGW on a Windows 7 machine, octave takes around 30 seconds to start every time. From what I have seen elsewhere, this is far from normal.
By "take 30 seconds to start" I mean from the time that I enter octave on the command line or initialize the octave.exe executable, it takes consistently 30 seconds to give the octave:1> prompt. Otherwise, it runs quite quickly, start-up is just agonizingly slow.
Something possibly relevant is that when watching resource manager, the octave process first peaks quickly in CPU usage as soon as it is called, then totally disappears in terms of CPU usage, than peaks again as it finally comes up.
I have searched for any other instances of this happening, and was unable to find any. This happens without loading any packages.
I'm guessing that your command prompt is starting octave at a very slow rate. Personally, I prefer using Console2 as an enhancement for the command prompt as you can set a path of the octave.exe and have it automatically load up in the window once you start Console2. It also gives you other additional features. This might or might not fix your slow start problem but I think it's worth a try:
http://robertcorvus.com/how-to-run-octave-in-console2/
Related
Longshot, but anyone had this issue?
I have code running (or not) which is set to run on the GPU. It fails to run unless I bump the GPU to make it run a little bit, for example by watching YouTube or playing a game.
I believe there may be some computer resource/application prioritisation/limitation configurations causing vscode to stop running, and wondered if anyone else had run into this issue.
I am running the code in a .ipynb notebook file in vscode (not sure if that might contribute to the issue). Sometimes the code will just freeze permanently, and I usually go about restarting the code to get things going properly.
The code should normally takes about 7 seconds for the training epoch, and 0.7 seconds for the validation epoch. But I was away for the first epoch and found it hadn't started, and so I opened up Youtube and it began.
Code timings
I can't think of what settings to change for this, but have tried a few
Power options
Anyone had a similar issue before? My second theory is that I think perhaps I am using too much GPU ram in my python code which is slowing it down and effectively made it freeze. And then when I load another application to use the GPU it forces the GPU ram to reconfigure and somehow this RAM reconfiguring might be unblocking the GPU allowing it to run again.
I have a new Win10 laptop. I've installed lots of software, including a 25-year-old Codewright editor that I've customized up the wazoo, and that I've been installing on all my machines for, well, 25 years. After working for a few days, it suddenly stopped, and reinstalling it didn't fix it. On startup, it puts up a small splash window, and normally opens the main window a half a second later (that took more than 5 seconds 25 years ago). It's not using any CPU, and there's nothing I can do but kill the process.
In the past, I've occasionally got my system into a state where Codewright would hang on loading, due to some other program that hadn't terminated correctly, and it was unfrozen by killing off that other process. So that's reason to believe that Codewright is waiting at some global lock which some other malfunctioning software is holding. So I have two questions:
Does this ring a bell? Is there some known failure mode where a program putting up a splash window then switching to another window can be prevented by something else going on the system?
Is there a way to diagnose this, perhaps by finding out what system call it's hanging inside? I tried dtrace.exe, started Codewright, and then stopped tracing, and it produced a 3GB XML file, which is quite a haystack. There's a way to filter it by PID, but since this is a startup problem, I have no idea what the PID will be. Is there a better tool for doing this, or some more appropriate dtrace feature that I missed?
The comment about using the Task Manager to create a dump file actually led me to notice that there is an Analyze Wait Chain function there that I had never seen before, since I haven't used Task Manager much since I switched from Win7. This gave me exactly the answer I wanted. My editor was waiting for something that was being held by some NVIDIA GeForce Experience module. Since I don't use that, I uninstalled it, and I'm back up and running. Thanks for the tip.
I have been using Pycharm 2019.3 with Python 3.6 as the interpreter and haven't had any issues until recently. The problem that I am having is that when I run a python script it takes a long time to finish. When I tried to stop the running script it takes about 5 minutes to fully terminate (stop) so I can run it again. Also, when I "terminate" the script I get a loading window saying "waiting for process to detach" and it takes 5 minutes, after that I can run the script and it runs fine but then again takes a long time to stop terminate completely so it can run again. It's frustrating since I need to run the scrip many times and I have to wait 5 min every time to re-run it :(
My configuration: Ubuntu 18.04 LTS with 16GB RAM
Any help is much appreciate it!
Thank you.
It looks like some other individuals have had similar issues with the console needing to be re-run when the stop button is used in Pycharm. Another person claims that they have to click stop twice on Ubuntu in order to get a process to terminate.
It seems like problems with terminating processes in Pycharm and other JetBrains products have been a long-standing issue that is hard to fix. Beyond, reinstalling Pycharm and possibly reinstalling your Python interpreter, this issue might just unavoidable with your specific hardware/os configuration.
I noticed that some common commands(ls, cat, touch, etc.) run very slow on my Mac. I couldn't find out why. So I use top to monitor cpu usage after I run some program in a terminal. I found that no matter what program I am running, a process called automountd pops up immediately and starts using lots of cpu (60% - 70%). I feel this might be the cause. If so, why this happened? What should I do?
Edit: I've confirmed that automontd/autofsd slows down my command line. After I kill the autofsd, ls and other commands become responsive. But disabling autofsd doesn't seem to be a perfect solution, so I hope someone can shed some light on this.
I use gnome shell in Fedora 18 x86_64 on an emachines E725 notebook. For the last month, every 60 seconds the display locks up for 25 seconds. Sometimes it does this for 10 minutes, and sometimes all day. The mouse cursor still moves, and sound still plays without skipping. Also, progress bars jump forward when it unfreezes as they never froze. I have stopped all cron tasks and restarted many times. The exact second the clock stops on varies each time I restart the system. I have also noticed a small increase in network use right before it freezes. It sometimes starts freezing before I open any apps, and it still freezes after I close all apps. Please let me know if there is any additional information I should post. I have done many convoluted google and stackoverflow searches over a long period of time and have found no similar problems posted. Thank you for any help or advice.
Probably off topic, but I'd suggest trying a CD/USB linux distribution (i.e. one that runs off the CD rather than having to install it).
If that has problems, you are probably looking at a hardware issue.
If a CD distribution works, then yep, it's something wrong with your installation.