Notebooks: Why do they take forever to open?

[AlfredBaldenweck]

This has been bothering me for a while. Pro 3.5

Why do Notebooks in Pro take forever to open or load? For example, creating a new notebook in an otherwise empty project takes really long, and opening a project  with a notebook window open takes like 20 minutes sometimes.

What gives? Does anyone have a consistent solution for this?

[ShareUser · Accepted solution]

This is a known ArcGIS Pro issue (especially 3.4–3.5).

Why it’s slow

Pro notebooks spin up a full conda + Jupyter kernel every time.

Environment drift or partial package installs make validation painfully slow.

If a project opens with a notebook tab already open, Pro tries to restore the kernel this is often what causes 10–20 min startups.

Corporate antivirus scanning Python/conda folders makes it worse.

What actually helps

Never save projects with notebooks open → open notebooks after Pro fully loads.

Clone and use a fresh notebook environment (don’t overload the base env).

Avoid heavy imports or auto-running cells at startup.

Exclude ArcGIS/conda paths from antivirus if possible.

Use external Jupyter/VS Code for heavy work; keep Pro notebooks lightweight.

It’s an environment + kernel startup problem, not your machine and Pro 3.5 made it more noticeable.

[HaydenWelch]

To add to this, it's often better to not use the Jupyter kernel/notebooks in Pro. If I want an environment, I'll open a notebook/interactive window in VSCode and directly interact with my data from there.

I have a library I wrote called arcpie (https://github.com/hwelch-fle/arcpie) that's meant to make interaction with aprx and gdbs easier in simple interactive script files outside pro.

You can do this while the project is open too, you just won't be able to save from the script as the active Pro session will take priority for mapping operations. If you instead hook into the project from an interactive session and open the project read only you can watch the changes made in the interactive session.

[AlfredBaldenweck]

Great tips, thanks.

[CordulaGöke]

It's great to know how to avoid it. Great it works ouside ArcGIS Pro. I ask myself now, why other programs have less problems to open the same notebooks. I have no option  to place it outside antivirus scanning. Since I saved projects in 3.6, I cannot downgrade any more, so I will try if arcpie works for me.

[ShareUser]

@VenkataKondepati 

Can I suggest that you place significant emphasis on the risks of excluding anything from anti-virus?

I've seen this advice from a few people in this sphere recently and it should only be done as a last resort and under very controlled circumstances. 
We do not know the skill level and proficiency of our readers and things like AV exclusions, registry edits, etc should be surrounded by appropriate warnings and caveats to prevent lesser skilled users from breaking things or exposing themselves to increased security risks.

I would also suggest anyone from Esri that gives this advice to overcome a particular user issue, at the same time lodge an internal case through their line management that covers the user scenario and the concept that Pro/Esri Stack Product should be made more resilient so that extreme measures such as registry edits or AV exclusions are never required.

Thank you so much for taking this comment to hart and aiming to improve things for all users going forward.

[ShareUser]

Hi @RTPL_AU,

Thank you for that feedback. You make a very important point. I completely agree that antivirus exclusions should never be the first step and carry significant security risks if not managed carefully.

In a corporate environment, these changes should be handled only by IT or Security teams, who can weigh the performance gain against the associated vulnerability. For individual users, it’s a 'last resort' move that requires a high degree of trust in the source of the files being excluded.

I’ve updated my perspective to include these critical caveats:

Never exclude folders unless you are in a controlled environment and have exhausted all other optimization steps (like environment cloning or project management).

If an exclusion is absolutely necessary, it should be as specific as possible (e.g., a specific Python.exe path) rather than a broad directory such as C:\Program Files.

I also take your point about feedback. If the software requires a security compromise to run effectively, that is a performance bug that needs to be reported to Esri through official support channels to drive long-term resilience.

I appreciate you keeping the conversation grounded in best practices!

[ShareUser]

I am not sure if it is for the same reason, but 3.6.x seems to worsen the problem even more. Additionally when I start tools there e.g. arcpy.management.XYTableToPoint() it takes at the moment >12 minutes, if I rerun the tool from history, it runs in 2 sec. I have reinstalled everything yesterday, where it would not open *.ipynbs at all.