So this is a bit of a weird one. To recreate the scenario, you need:

1. a version of Minecraft with the Fabric mod loader
2. a resource pack that offers optifine-style emissive item textures, such as John Smith Legacy
3. Continuity installed and either A) Model Gap Fix or B) Item Model Fix set to the "Pixel" fix option.

For reasons I don't quite understand, items that have emissive textures result in a massive performance drop when the two aforementioned mods are used, and Continuity has "Emissive Textures" on.

Example of a chest with some random items:

And another chest with a bunch of lava buckets, which use an emissive texture, even though it's basically useless as an inventory item preview. For reference though, the lag occurs so long as the item's icon shows anywhere, be it in an inventory, held on hand, or dropped and floating on the ground somewhere:

Disabling the "Emissive Textures" option in Continuity sees the framerate from either mod drop equally, though nowhere near as bad as when it was on previously. I have not tested whether the same situation occurs in Forge with Optifine to be 100% sure that this is Continuity, but then again I find it rather improbably that two independent mod makers made the exact same mistake that'd cause this big a loss in performance.

Item emissives work by doing some operations on every quad of the item model every time the model is rendered. Continuity finds the sprite, checks if an emissive sprite exists, and if so, the quad is copied and its sprite is replaced with the emissive sprite. Since items are rendered every frame and none of the final geometry or emissive geometry is ever cached, it is not surprising that item models with a lot of quads will cause a decrease in performance.

I have had the idea to pre-generate the emissive geometry for static models, which would be quite effective since almost all models are indeed static. However, doing this well is not trivial and I am still busy with 1.19.3 and other improvements at the moment.

Ah, that explains the lag then, as both mods offer a method of tackling these gaps by doing quad adjustments -- this is heavy by itself when there's a lot of items to display, and it sounds like that same work is being done multiple times due to how Continuity is tackling emissives itself.

Nevertheless, I'm glad to know that you are aware of this situation. Caching some of this work would surely be nice, but perhaps one convenient alternative would be to break the emissive texture handling to multiple categories? Since the gap fixing only needs to occur on item models, you could potentially offer a dedicated switch for it, so all other emissives from blocks will still run? Would that work?

It is possible to offer separate options for block and item emissives in the configuration menu, but I don't know if it is a good idea. The less options the user has, the less likely it is for them to get confused or accidentally turn something off. Caching emissive geometry would entirely solve this problem, so I don't think it's worth adding in a temporary workaround.

I'm of the mindset that it's alright to have a few extra options if they're clearly explained, and they're not just being pedantic bloat, but I see your point nonetheless. I'll stick with other gap fix methods for now that don't touch model quads :)

Ah, that explains the lag then, as both mods offer a method of tackling these gaps by doing quad adjustments -- this is heavy by itself when there's a lot of items to display, and it sounds like that same work is being done multiple times due to how Continuity is tackling emissives itself.

Nevertheless, I'm glad to know that you are aware of this situation. Caching some of this work would surely be nice, but perhaps one convenient alternative would be to break the emissive texture handling to multiple categories? Since the gap fixing only needs to occur on item models, you could potentially offer a dedicated switch for it, so all other emissives from blocks will still run? Would that work?

No, the gap fixing also occur on block models too with Model Gap Fix
MGF also fix block models since the issue also appear on block models even tho it's usually harder to detect unless you use custom block models
https://bugs.mojang.com/browse/MC-73186