Automate the .saveACopy() ArcPy method to reduce MXD file size

[CarlBeyerhelm]

I have a folder of 50+ MXDs that have been edited repeatedly, such that their file size has increased over the course of time.  Applying File - Save A Copy from ArcMap, or the mapDoc.saveACopy() method in the Python window will reduce the current MXD's file size...but only for the MXD that is currently open in ArcMap.  Applying the mapDoc.saveACopy() method to a long ArcPy list of MXDs does, indeed make a copy of the MXDs, but it does not also reduce their file size.

So, the question is, is there a way to automate MXD file size reduction?  I've explored the os.startfile(mxd_path) scenario, but it opens a new instance of ArcMap for each MXD...which is not satisfactory.

Advice or insights are welcome.  Thanks...

[ChrisPedrezuela · Accepted solution]

I tried this,

import subprocess

subprocess.call(['C:\Program Files (x86)\ArcGIS\Desktop10.2\Tools\DocDefragmenter.exe', r'sourcefilepath', r'targetfilepath'])

Regards,

[CarlBeyerhelm]

Thanks for the suggestion.  This approach does represent a solution, though not quite what I had hoped for.  It's shortcomings are that it is very slow because DocDefragmenter has to be re-executed for every MXD in mxdList (about 4.5 minutes to process 37 MXDs vs 8 seconds using the native DocDefragmenter executable), and the command line form of DocDefragmenter does not accommodate the same range of options available in the native DocDefragmenter dialog.  Nevertheless, it is adequate for situations where a scripted, non-interactive MXD file size reduction is required.  Otherwise, just running the native DocDefragmenter executable would be faster, and offers more options.

Here is the working snippet that I tested...

import arcpy, subprocess

docDefrag = r"C:\Program Files (x86)\ArcGIS\Desktop10.1\Tools\DocDefragmenter.exe"

inFolder  = r"C:\Workspace\projects"

outFolder = r"C:\Workspace\projects\backups\BackUp1"

arcpy.env.workspace = inFolder

mxdList = arcpy.ListFiles("*.mxd")

for mxd in mxdList:

    inMXD  = inFolder  + "\\" + mxd

    outMXD = outFolder + "\\" + mxd[:-4] + "_Defrag.mxd"

    argList = []

    argList.append(docDefrag)

    argList.append(inMXD)

    argList.append(outMXD)

    subprocess.call(argList)

[ChrisPedrezuela]

I agree Carl, I've been looking for other ways before actually, some lead to doing something with ArcObjects rather than python. But just for a stop-gap solution, and just utilising what already exist, this might suffice. You might also just create a batch command file as well and run as  a schedule task.  Although I read MXD doctor does a similar job in reducing file size as well.

Regards,

[JoshuaBixby]

Although this won't address the immediate need for a workaround, I think there is a bug here.  If one uses MapDocument.saveaCopy and specifies an earlier version, like 10.0 from 10.1 or 10.2, the output of the saved MXD is dramatically smaller on several large MXDs I grabbed.  Basically saving from ArcMap to any version shrinks the file size and saving from arcpy to previous version shrinks the file size, but saving from arcpy to current version doesn't.

I have a bit more digging before deciding whether to open an Esri Support case/incident.

[CarlBeyerhelm]

Thank you.  That is interesting.  I hadn't explored the nuances of saving down to prior versions.  So, yes, it does seem like a bug if saving down to prior versions from arcpy results in smaller file size, but saving from arcpy to the current version does not reduce file size.

[JoshuaBixby]

A bug on this issue has been opened with Esri Support.  As of now, no timeline for when it might be addressed.

Esri Support:

Bug BUG-000081100: Arcpy.mapping.MapDocument.saveACopy() does not work the same as the ArcMap Save A Copy functionality. The output mxd is not compacted.

[CarlBeyerhelm]

Thank you...

[JoshuaBixby]

Heard back from Esri Development, "this is very much a known limit."  It seems to a handful or two of folks in Redlands, this is "very much" known; unfortunately up until now, no one has bothered to share it with ArcGIS users by actually documenting it.  At least now they have a bug to document it and to document they aren't going to do anything to address it.

I "very much" get this response too often, can't help but think there is a hashtag reply in it: #findanotherworkflow #SOOL.

[curtvprice]

What's making your mxds grow so much? Geoprocessing history? There are settings you can do to keep that from getting way out of hand if that is the main issue.

You can test this by opening the MXD and opening the GP results, delete some history and see how much it shrinks your MXD.