Double upstart issue

[phifuh]

I am in a very frustrating situation. To share our application, we need to run it on a network drive, and some colleagues using VPN literally take 10–15 minutes to open the program. I am still in "research" mode to understand what's happening and how to increase performance.

One obvious time saver is reducing the .exe file size, but we already cut it down to a bare minimum. Next, I looked at the job processes and noticed that the app looks like it loads twice. The first process slowly fills up to 80 MB, and then the second one does the same.

This isn't "new" behavior. I first noticed this issue in 2024 with FastAPI, where the application started twice, and I noticed the same behavior in NiceGUI for a long time.

My questions are: How can I debug/track this? And what do you need from us to better track down this problem (if it is any issue at all)?

[falkoschindler]

Thanks for the report, @phifuh!

What you're seeing is a known issue tracked in #5684: when Python spawns subprocesses (for reload, native mode, cpu_bound(), etc.), each subprocess re-imports the main module, causing NiceGUI's initialization to run twice. Running from a network drive makes this much worse since every duplicated import triggers file I/O over the network.

Immediate workarounds:

• Use reload=False and guard your code with if __name__ == '__main__':
• Set NICEGUI_INCLUDE_MATPLOTLIB=false if you don't need matplotlib (~70% of import time)
• If possible, run the app from a local copy rather than the network drive — this alone should dramatically reduce startup time
• Try PR Lazy imports for ui module using PEP 562 __getattr__ #5303 (lazy imports) — it should significantly reduce the redundant import overhead. We'd love your feedback on whether it helps in your network drive scenario!

[falkoschindler]

@phifuh The 70% refers to import time, not disk space. We intentionally keep matplotlib bundled because NiceGUI aims to be "batteries included" — most things should just work without installing extra packages for every feature. With lazy imports (#5303), matplotlib would only be loaded when you actually use ui.pyplot, so the overhead disappears for everyone else. That's why feedback on that PR from your network drive scenario would be really valuable!

[evnchn]

If there really is strong demand that a lite NiceGUI to be batteries-free, the approach would be to make, somewhere, a nicegui-core which is that, and the main nicegui library to invoke that.

It is the case for Pydantic (https://github.com/pydantic/pydantic/tree/main/pydantic-core), and NiceGUI might just need that if it wants in-browser execution support (ref: #5776).

However, that adds to maintenance burden, and as such I think we are not putting that as high priority unless a firm use case calls for the separation. Pyodide is not a very valid use case to be frank, but I'd also want to know more about your network drive scenario. Particularly is a small exeuctable non-negotiable (so local copies are non-workable, despite you can do SHA256 hash check to lock out the old executable from running and auto-download the new executable?)

[phifuh]

I can give you a little bit more context.

Our app is somewhat a CRM where you select files and later it's building a website, so first, on export, all content is loaded. In the enterprise setting, we have 4 options to deploy the app:

1. Citrix
2. Network share
3. Deploy a package
4. Run local as admin

We tried option 1. The lag was horrible and we encountered a new "connection lost" issue, so we quickly discarded that option.

Option 2: It's working. Performance is almost as good as local, but the startup time is killing us. We're on a special healthcare "network," so each location has this network, and if you want to work at home, you get a VPN to access it. The startup time on VPN is between 15–20 minutes that's just not good enough. Right now, we don't have a splash screen, so users don't even know if something is happening (obviously, we will add that, but still).

Option 3: Deploying a package to 33,000 people when only 20 need access to this app is not feasible from an organizational view. A lot needs to happen regarding security, and this whole process takes a lot of time (multiple month).

Option 4: Giving users "global" admin permissions to run it locally is also problematic. Since the company works with sensitive healthcare data, security has a high priority, and handing out admin rights to non-technical people isn't a great idea.

Tonight, I kinda had the same idea as @evnchn. I considered making a mini NiceGUI, which strips it of all the "bloat" to reduce the package size. Right now, the NiceGUI lib fills 75% of the whole package, which is a lot and definitely could be reduced.

[evnchn]

1 seems like Citrix compatibility issue. If WebSocket is dead, then consider disable WebSocket and use HTTP polling transport (past successfully helped another NiceGUI user on corporate network to work IIRC) #5468 (comment)

2 is what you use and our replies apply.

3 you can distribute packages locally without involving pip. Was what used in my prior internship, so consider it.

4 is a no-go.

For the lite NiceGUI, if you have Agentic AI and don't mind use some credits, feel free to get started. I just lack the bandwidth to solo that.

[phifuh]

You can always get something to work one way or the other, but you might not see the full picture. Large enterprise companies with 33,000++ employees have a very different IT infrastructure in comparison to mid-sized or small companies, so I am looking into ways that I can influence the situation, which wont invoke large scale IT changes or involves multiple appartments. Plus, there are very tight and, to some degree, unrealistic deadlines. I know it's easy to say, "Well, it's a 'you' problem."

As far as I see it, package size is the biggest leverage I have. We already experiment with different compilers, and Nuitka seems very promising over PyInstaller. Alone, that reduced loading time from 15+ minutes to 6 minutes.