If the 64-bit Background Geoprocessing for ArcGIS Desktop 10.1sp1 is installed how does that affect Python configuration for general use?

Esri has released SP1 for the ArcGIS 10.1 product, and for the Desktop component has made available a 64-bit Python 2.7.2 instance that when installed replaces Esri 32-bit Python 2.7 calls with 64-bit calls for background geoprocessing (processing sent out side of an active ArcGIS Desktop GUI session).

Installation is optional--i.e. without it ArcGIS Desktop continues with only 32-bit user memory space available. With it, a \bin64 entry is made to the Esri program folder, and registry keys are established for 64 bit processing at "HKEY_LOCAL_MACHINE\SOFTWARE\ESRI\ArcGIS 10.1 SP1 for Desktop Background Geoprocessing (64-bit)" and background geoprocessing is then done in 64-bit memory space.

Both Esri's 32-bit and now its 64-bit Python are full 2.7.2 installations.

During background geoprocessing Esri's registry, path and configuration files take care of calling the 64-bit Python executables. While use of 32-bit Python is retained in the ArcGIS Desktop session where needed.

So, what is left to each user is decide whether to integrate the installed 64-bit Python 2.7.2 into their computing needs outside of ArcGIS. And how best to do that when both 32 and 64 bit versions of Python are resident on the system?

Asked another way--Esri takes care of integration of 64-bit Python within its ArcGIS Desktop, so what ways will work to configure it for the rest of the use cases beyond ArcGIS?

  • Just curious, did you use Process Monitor or some such to monitor the installation of this package? Was thinking of doing that myself. – blah238 Nov 2 '12 at 1:33
  • no, just reviewed changes in file system and registry – V Stuart Foote Nov 2 '12 at 2:24
  • 3
    I did a quick before & after 64bit Background Geoprocessing performance test - not sure if slight (10%) improvement only is what should have been expected. – PolyGeo Nov 2 '12 at 4:52
  • 4
    @Arabella - I wouldn't expect swapping to 32bits to make anything faster and the 10% improvement linked doesn't seem statistically significant. The main difference is that the 64bit version will allow the geoprocess to use more than 4GB of RAM. Anything else will be tangential. – GIS-Jonathan Nov 2 '12 at 10:27
  • 2
    @PolyGeo - Fundamentally, the core difference between 32bit and 64bit is that 32bit applications can't use more than 4GB of RAM (they simply can't address it - actually more likely 2GB or 3GB on Windows depending on flags and stuff). Anyway, to truly see the benefit of 32bit versus 64bit you'd need to perform a test that would use more than ~4GB of RAM. Of course, there may be optimisations ESRI have done between the versions, but the 32/64bit-age itself only deals with RAM use at its core level. – GIS-Jonathan Nov 6 '12 at 14:47

So, what is left to each user is decide whether to integrate the installed 64-bit Python 2.7.2 into their computing needs outside of ArcGIS. And how best to do that when both 32 and 64 bit versions of Python are resident on the system?

As I understood you are asking the way we can distinguish different versions of python and use it according to our needs.

The easiest way is to exactly specify the interpreter you are going to use to run your script. More details can be found in this SO q/a.

| improve this answer | |
  • In a sense. But I'm more interested in doing this programatically during scripting. How to toggle PYTHONHOME and PYTHONPATH, and then manipulate them with sys.path.append() calls or site.addsitedir() to reconfigure the system to use either 32-bit or 64-bit Python. Suggestion in the SO q/a of just calling one Python version or another is kind of coarse. Challenge would be for finesse to flexibly make use of the site module and to work reliably in an IDE. Beyond simple path and site-package manipulation, possible to have multiple Python configs with virtualenv of 32-bit and 64-bit environments. – V Stuart Foote Nov 9 '12 at 7:16
  • In your script you can try to call execution of other python script by calling it with needed interpreter (x32 or x64) from command-line using subprocess module for example. – Alex Markov Nov 9 '12 at 7:47

For me, this is what was required... and I'm still not sure everything is working 'properly'. After I installed the 64bit Background Geoprocessing tools and changed my PYTHONPATH to use them (from e.g. default python), it seems it broke everything insde ArcMap (e.g. 32bit console python). So I came up with the following work around. YMMV

1) Download and run the 64bit background geoprocessing tools: Luckily I found it once! I can't seem to find the link again...

2) Add the following to the system PYTHONPATH (assuming you're using 64 bit by default): ;C:\Python27\ArcGISx6410.1\DLLs;C:\Python27\ArcGISx6410.1\lib;C:\Python27\ArcGISx6410.1\lib\plat-win;C:\Python27\ArcGISx6410.1\lib\lib-tk;C:\Python27\ArcGISx6410.1;C:\Program Files (x86)\ArcGIS\Desktop10.1\bin64;C:\Program Files (x86)\ArcGIS\Desktop10.1\arcpy;C:\Program Files (x86)\ArcGIS\Desktop10.1\ArcToolbox\Scripts

3) Create a startup script for Arcmap Python so it doesn't get confused with 64 bit imports from the PYTHONPATH

import sys
if sys.executable in ['C:\\Python27\\ArcGIS10.1\\python.exe', 'C:\\Program Files (x86)\\ArcGIS\\Desktop10.1\\bin\\ArcMap.exe']:
    print('Resetting Path')
    sys.path = [
        #python32 for ESRI
        'C:\\Program Files (x86)\\ArcGIS\\Desktop10.1\\bin',
        'C:\\Program Files (x86)\\ArcGIS\\Desktop10.1\\arcpy',
        'C:\\Program Files (x86)\\ArcGIS\\Desktop10.1\\ArcToolbox\\Scripts',

import arcpy 
from arcpy import env

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.