Current Python Version 2.7.10 - I have tried a straight download from python.org and the Anaconda distribution.
Previous Python Version was 2.7.x (don't remember) - I know it was an Enthought Canopy distribution.
I just 'upgraded' windows from 7 to 10pro. I reinstalled everything on my computer for a fresh start. I installed the most recent version of Python 2.7.10. I am now running a script that I was running just yesterday on my Windows 7 OS, and it is running incomprehensibly slow now, and I have no idea why. It is a script that is based on the code from a tutorial found here:
http://pythonprogramming.net/sentiment-analysis-module-nltk-tutorial/
It has a lot of data that is loaded, and it wasn't running super fast before, but now it takes so long, it looks like it's frozen. Any thoughts? I thought that it had something to do with packages that I had installed on my previous Python environment, like a C-compiler or something. The output is nothing, because it just hangs for a long time and slowly moves through the script. It isn't broken, there isn't a loop it's stuck in. If I wait long enough, it will start showing me the correct output. When I hit 'Ctrl-C' this is what I get.
python -mcProfile MAIN_Tutorial_2.py
forrtl: error (200): program aborting due to control-C event
Image PC Routine Line Source
KERNELBASE.dll 00007FFB485B5674 Unknown Unknown Unknown
KERNEL32.DLL 00007FFB49412D92 Unknown Unknown Unknown
ntdll.dll 00007FFB4B819F64 Unknown Unknown Unknown
Don't think that helps, but just in case.
I've been struggling for a while with similar topic - long start up time of python scripts.
This is what I've found on python documentation site:
Why does Python sometimes take so long to start?
The problem may be caused by a misconfiguration of virus checking software on the problem machine. Some virus scanners have been known to introduce startup overhead of two orders of magnitude when the scanner is configured to monitor all reads from the filesystem. Try checking the configuration of virus scanning software on your systems to ensure that they are indeed configured identically. McAfee, when configured to scan all file system read activity, is a particular offender.
Unfortunately, I don't have a quick way to test whether disabling file system protection will help, so I hope it will solve your problem and will be glad to hear from you.
Related
I have a GCC 3.4.3 toolchain built for ARM (arm-elf) here in my Windows 7 (64bits) setup. We use this to build our software product to a specific hardware.
Recently, we have been experiencing some problems with this particular toolchain.
First, when we try to call arm-elf-gcc to build each source file (there are lots of them), it complained about it not being able to allocate enough heap.
Then, I thought it was some problem with the outdated cygwin DLL distributed by the hardware vendor. So I replaced it with a more recent version (1.7.35). The problem stopped and the build does go ok but now it is incredibly SLOW (it took about 40s to build a single .c source file).
Does anyone has experienced this problem before? How can I debug and fix it?
Thanks in advance.
Sounds like you have had a similar problem to me and might be worth trying this. When i first encountered this, I had to install cygserver and then run this (make sure you right click admin):
Previous solution
However, the problem resumed and I simultaneously couldn't install/uninstall some problems. Eventually I resolved this by terminating SearchIndexer.exe in Task Manager. Indeed, I have gone in to Control Panel / Searach Indexing and pulled it back from doing any indexing. My installation taking 1hr took 3 more seconds. The change to Cygwin was instantaneous.
Cygwin is now flying!
I've had an issue with slow execution of builds for a while on cygwin, using make and a proprietary compiler that "isn't gcc, honest...", but has very similar error returns.
I was forced to update yesterday and ran into the issue of rebaseall simply failing to execute. This forced me to dig into other things and I found a report that Trusteer Rapport/End Point Protection has been known to cause issues with rebaseall,and slow response times. So I removed it. This fixed the rebaseall, but has also massively increased the speed of my build. Worth checking to see if you have it installed, try removing it. AV packages in general are reputed to interfere and may be the cause.
I installed the gdal module for python a week ago, via the GDAL Complete 1.11 Framework Package. I wrote a program which relied heavily on gdal and osgeo and ogr to work with shapefiles (.shp) and rasters (.TIF). Today, without changing my code at all, when I ran it in the terminal as I usually do, I got back:
Bus error: 10
Since I hadn't changed anything with my code, I looked to see whether the problem was with one of my imports. When I commented everything out besides
from osgeo import ogr, gdal
I got the same error, similarly for when I just ran python in the terminal and tried
import gdal
I read that Bus Errors are caused by non-existent memory addresses, so I thought the module might somehow not be there anymore, so I listed my modules using
["%s==%s" % (i.key, i.version) for i in pip.get_installed_distributions()]
and gdal was listed in there. Anyway, that wasn't necessarily the best thought since python throws an ImportError for modules it doesn't recognize. Other imports, like numpy, math, time, and datetime all work for me. Since bus errors are a sort of hardware fault with the memory, I tried a soft and then a hard reboot, still getting the same bus error. In fact, since I restarted my computer, it's been dreadfully slow. So my first question is why the Bus Error occurred and how to fix it, and second, I'm wondering how to get my computer back up to speed.
Last night, I dropped my computer in its case, but gdal (and seemingly everything else) was working fine this morning, until this error came about.
I appreciate your time and input.
I'm having a very strange problem. I'm using dfs-datastores Pail abstraction to write data to HDFS in Java. I don't think the Pail piece is important to the problem though.
When it calls org.apache.hadoop.fs.FileSystem getFS(java.lang.String path) with a path on my local filesystem it pauses for about 2 minutes seemingly doing nothing then returns. This is on my laptop.
The weird thing is that it worked really fast when I was on the network at my office today, but now that I'm home it's doing it again. I'm running Ubuntu 10.10 64-bit with Java 1.7.
Anyone have any ideas what it's doing? What could be different between being at work and being at home?
UPDATE:
I've been stepping through code with the debugger and it seems to be having trouble in Configuration.loadResource(). It's calling that multiple times and it will take 5-10 seconds to return from that function.
UPDATE2:
I've narrowed this down a little further. The biggest hang up seems to be when it calls KerberosName.setConfiguration(). Which would explain why it runs fast at work since the Active Directory acts as a Kerberos server. I don't have one here at home, so it can't find one. Now they question is why in the world it's trying to load the Java Kerberos stuff.
I found a solution (or at least a work around). I installed the krb5-kdc package and now my little program runs fast without any unexplained pauses. After this I removed krb5-kdc, tested and it was still running fast. I removed /etc/krb5.conf and it started doing the pause again. It looks like using the Hadoop library on Ubuntu (at least) requires a /etc/krb5.conf file.
Maybe this will help someone else.
I have an issue on our Windows 2003 x64 Build Server when invoking shell commands from a script. Each call causes a "memory leak" in the page file so it grows quite rapidly until it reaches the maximum and the machine stops working.
I can reproduce the problem very nicely by running a perl script like
for ($count=1; $count<5000; $count++)
{
system "echo huhu";
}
It is independent of the scripting language as the same happens with lua:
for i=1,5000 do
os.execute("echo huhu")
end
I found somebody describing the same issue with php at
http://www.issociate.de/board/post/454835/Memory_leak_occurs_when_exec%28%29_function_is_used_on_Windows_platform.html
His solution: Firewall/Virus Scanner does not apply, neither are running on the machine.
We can also reproduce the issue on other Developer Machines running XP 64, but not on XP 32 Bit.
I also found an article describing a leak situation in page file at
http://www.programfragment.com/
The guilty guy for the allocation is C:\WINDOWS\System32\svchost.exe -k netsvcs which runs all the basic Windows services.
Does anybody know the issue and how to resolve it ?
We found the issue by reinstalling a similar step by step. It seemed to be caused by a bug in a hardlock driver. After installing a newer version of the driver the issue disappeared.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.