Hi,
during internal tests we noticed a big impact on startup time (~30s vs 90s) on en- or disabling extensions in pyrevit. So not disabling pyrevit, but rather en- or disabling extensions in it. What affects the performance the most? How can we optimize internal extensions to improve startup time?
==> Registered Clones (deployed from archive/image)
master | Branch: “master” | Version: “5.0.1.25051+1239” | Path: “C:\Program Files\pyRevit-Master”
==> Attachments
master | Product: “Autodesk Revit 2024” | Engine: DEFAULT (2712) | Path: “C:\Program Files\pyRevit-Master” | AllUsers
master | Product: “Autodesk Revit 2022” | Engine: DEFAULT (2712) | Path: “C:\Program Files\pyRevit-Master” | AllUsers
Yes.
This is kind of expected as the loader parses extensions at startup.
The operation is actually done in pyrhon, but there is a refactoring initiative in C# by @romangolev (and we should all be grateful, because it is no small task)
This should greatly improved the situation.
While the folder structure is pretty sweat and easy to understand, parsing through files and folders is kind of busting the starting time depending on how many tools and extensions you have
The new feature in Revit to manage add-ons gives you a hint at which addin s take more time than other.
How to optimize on your side, make icon small (96px), minimize your code base and make it as modular as possible. That’s all i can think of.
1 Like
Hi, @pyrevti
That’s completely true what @Jean-Marc said. As for now the more active extensions you have, the longer it takes for the pyRevit to start. Actually it’s also applicable for All the Revit add-ins as well. As for pyRevit, I am actively working on the implementation for the optimized loader which should decrease the loading time.
The way it’s done now is that we have loader module which is written in python and being executed with IronPython language runtime which itself converts the code to .NET. When implemented, the new C# module should show much better speeds boosting the loading.
3 Likes