Improving PyRosetta Initialization

[CarlosChacon-cell]

Hi!
I am using PyRosetta to score some protein binders, getting info such as the neighboring residues, interface hydrogen bonds (saturated and unsaturated), dSASA and so on.
I have noticed that PyRosetta intialization employs a lot of computation time, with the first design scoring taking 4 more time than the rest, independent of the protein sizes.
I wonder if there is a way to make PyRosetta initialization more efficient.
The PyRosetta version I am using is:
pyrosetta 2025.06+release.029c6a159b py310_0 https://conda.graylab.jhu.edu
If you need more info, i would try to answer as soon as possible.
Thanks !

[ajasja]

I think an easy trick is not to initialize pyRosetta for each scoring. If you are scoring 10.000 structures, make 10 paralel workers that each score 1000 structures instead of 10.000 workers that each score one structure.

In general I agree it would be very cool if initialization was faster, but pyRosetta has to do a lot of work, including reading from many small files.

[CarlosChacon-cell]

Thanks for the suggestion! I agree that's probably the most straightforward solution, but due to how I plan to structure my implementation, it's not a viable option for me.

I'm still trying to fully understand how PyRosetta handles initialization under the hood. Do you think it would be possible to perform a "dummy" initialization step that caches the required data (either in memory or in a specified folder), and then have PyRosetta read from that cache in subsequent runs? I’ve seen similar strategies work with JAX, so I’m wondering if something along those lines could be adapted here.

If you think this is feasible and can point me to where in the PyRosetta codebase I should look to start developing this, I’d be more than happy to dig in and give it a shot!

[ajasja]

Hmm, that's not actually a bad idea, but not sure how feasible it would be technically. The idea would be to load all the databases and score functions etc and dump the pickled to disk for subsequent pyrosetta loads. Adding @lyskov @roccomoretti @klimaj, since I am sure somebody had that idea before :)

[ajasja]

Maybe just try dill to pickle on the python side (but with PyBind not sure how it will work) or maybe checkpoint the entire process using https://criu.org/Main_Page or maybe combine with docker https://criu.org/Docker. Apptainer also has checkpointing. https://apptainer.org/docs/user/main/checkpoint.html

[klimaj]

PyRosetta initialization sets some global variables, so ideally it ought to only be run once per thread/process. In some cases, one can set certain flags and variables after initialization (e.g., using pyrosetta.rosetta.basic.options.set_real_option) or set certain data using other PyRosetta methods, but whether this works or not depends on the specific movers/filters/metrics/etc that access the data. Could you please post an example of the pyrosetta.init flags you're using? In particular, which flag(s) do you suspect are slowing initialization down?

[ajasja]

I think just loading the Rosetta database is slow?

[klimaj]

I see, if that's the case, I agree with your previous suggestion to pre-initialize workers and submit tasks to them (which would minimize the number of PyRosetta initializations that need to be performed). If that's not a viable solution based on the implementation, maybe it's easier to ask how the implementation could be restructured to use this framework? On the other hand, if the PyRosetta database is mounted over a network file system with low bandwidth, that could slow down PyRosetta initialization, since it would need to load a large database over the network. That's strange that the first initialization takes 4 times as long -- maybe the file system is caching data locally. If that's the case, maybe you can just tar compress the database onto the local drive, and decompress just before initialization.