The method: CommonCapabilities::CapabilityConstructorRegistry_onItemStackLoad is being called an obscene number of times when profiling my server. The breakdown of which can be seen here: https://gyazo.com/81beda25418472e1e7a6bafd2be09545

I'm wondering if something is going awry.

Running SpongeForge, Forge 2022 on Minecraft 1.10.

Full profile: https://timings.aikar.co/?id=65fe1c16b4084a008ed5fe31238920c2&section=lag

@Rob5Underscores I see you're using CyclopsCore 0.9.0. Version 0.9.1 contains performance improvements for this exact problem (CyclopsMC/CyclopsCore#35). So a simple update will fix this.

P.S. I really like that profiling website, it contains all the information I need!

@rubensworks
I backported the 0.9.1 changes to a mod packaged as 0.9.0 - dirty/unsupported I know but still getting the following:

https://timings.aikar.co/?id=30919d1000c94357981693d562cc3e0e&section=lag

@Rob5Underscores Why don't you simply update?... There are also changes to CommonCapabilities itself, which should be updated.

I've updated now (as the pack updated), but I am tied to whatever the modpack uses.

@rubensworks
https://timings.aikar.co/?id=8948d9dc4c834fcda445426a93b7197d&section=lag
Using CommonCapabilities 1.9.4-1.2.2 and CyclopsCore 1.9.4-0.9.0-469.

Still a lot here:
https://gyazo.com/4b3ffab98bcbda53f45ca745dca565ff

Also (or maybe related to above): Colossal chests as external storage of RS is still bad? - maybe an RS problem? (Using refinedstorage-1.2.17)

@Rob5Underscores In your new logs, the CapabilityConstructorRegistry doesn't seem to be a major contributor to lag anymore. It's still present, because of it's required interaction at each ItemStack copy, but much more efficient than it was before.
Other mods like EnderIO, Botania, XU2, ... seem to be a much bigger contributor to the lag, but still not significant.

Thanks for your help.

Going to attempt a backport of RS 1.2.19 to 1.2.17.