Copy and Project Features Slowing Down Script in Python Window

[deleted-user-1_r2dgYuILKY]

I have a script that copies thousands of features, performs analysis and then deletes the copies. When I run this script in the Python window in ArcGIS Pro 2.3.1, each feature is copied and displayed in the TOC (ex. feature_new), and then is deleted. However, each time this happens, another copy with the original feature name and a number (ex. feature_old26) is created in the TOC, and remains after the script moves on to the next feature. So I have thousands of these in the TOC (see photo). If I use arcpy.env.addOutputsToMap = False in the script, the script immediately fails on copy features. ERROR 000732: Input Features: Dataset feature_old26 does not exist or is not supported. I know that this particular bug was logged almost a year ago (BUG-000116163), but I can't find any information about it. 

The issue I have with this is that it's dramatically slowing down the Python script execution over time as hundreds or thousands of features build up in the TOC. I would run it in standalone IDLE, but for some reason it's faster in the Python window at first. 

[DrewFlater]

Hi,

The bug you linked, BUG-000116163, is not fixed yet. It deals specifically with arcpy.MakeFeatureLayer_management() when arcpy.env.addOutputToMap = False. 

If your script is only doing a CopyFeatures then it might be a different issue that the script is failing. You do say after the copy the script "performs analysis" so I guess this may include arcpy.MakeFeatureLayer_management? You might be able to rewrite some steps in your script, as Make Feature Layer is no longer required as a pre-requisite for many tools like Add Join, Select Layer By Attribute, etc, as of Pro 2.2. https://pro.arcgis.com/en/pro-app/get-started/what-s-new-in-arcgis-pro-2-2.htm#ESRI_SECTION1_68F7BAF... (see the second bullet point) 

[MatthewDriscoll]

You also might try creating the features in memory, there would be no need to delete them.

[deleted-user-1_r2dgYuILKY]

No, MakeFeatureLayer is not part of the script. It's peeling off and copying individual rooms from buildings, generating a tessellation for the room, select by location to count the hexagons and then moving on to the next room. All of those interim steps are deleted each time. The problem is, every time there's a copy of a room, another copy of the main feature class (all the buildings) is created in the TOC with a number at the end. That's filling up the TOC, and as far as I can tell, slowing the script down. When it starts, it's taking 40-45 seconds per room. After several hours it's up to around 3 minutes. Has anyone seen that happen before? It's very strange. Would creating the copies in memory solve this issue?

[JoshuaBixby]

Please provide the code that is removing the layers from the TOC, or is the user doing it manually in the GUI?

[deleted-user-1_r2dgYuILKY]

It's not removing them from the TOC, but the scratch.gdb. Pro is adding these copied layers to the TOC during the analysis, and then they are removed once they're deleted from the geodatabase. I'd rather they aren't added to the map at all, but due to that bug, I can't control it.

To reiterate: I have one feature class with nearly 100 buildings that's been converted from CAD. The script goes through each building, copies out each room, runs analysis, and moves on to the next room. What's building up in the TOC is unexplained copies of the original feature class (see photo above) that are happening in tandem with the room feature copy. That is a feature class with 12400+ rows copied over and over again in the TOC. I believe it's clogging up the memory and slowing the Python script way down.

Update: I believe this is a problem with the Project tool. I just tried to write the interim steps to memory and got this ERROR 000944: Output feature class cannot be in the in_memory workspace. Failed to execute (Project). 

Here is a better illustration of what's happening. The bottom feature is the original, the top feature is a single room that's been copied (based on an attribute selection from the main feature) and projected to the coordinate system based on the central meridian of the room. The middle feature is the copy of the original that remains in the TOC. Its source is identical to the main feature class, so I believe it's just being copied in memory by Pro. 

[MatthewDriscoll]

I believe you still need to make a feature layer from your feature class if you are going to run it in_memory.

[deleted-user-1_r2dgYuILKY]

OK, but I still think there there is a bug here. There should not be extra copies of the original feature class clogging up the TOC. 

[MatthewDriscoll]

Hard to say without seeing the code.  You may not be finishing the loop cleanly before moving onto the next one.  If it is clean I recently learned that MapView.Redraw was introduced in 2.2, you might give that a try before moving onto the next one.

[JoshuaBixby]

How or where are you executing this script?  From the behavior you are seeing, I am guessing from the interactive Python window and not a script tool.  Also, I agree with Matthew Driscoll‌, we really need to see some actual code to give more substantive feedback.