Are you use physics engine? - maybe you need to disable it on low settings for casio users stop crying.
Physics in itself don't cost much at all when there is nothing demaning around that uses it. It can be demanding, but the game isn't using anything that does with a few exceptions. In the touch/spank mode, it uses real time softbody modification which used the fast bullet engine as a backend. I made the integration of bullet and the whole softbody system from scratch and it uses mostly GPU as well as multithreaded burst threads. However, performance of this is generally irrelevant anyway, as this is not active in any other part of the game, so it's not really an issue.
The other thing that could be considered physics is the bone simulation of tits and ass. This doesn't cost anything since it's a simple bone-spring calculation. Same for clothing like her ribbon on the chaos dress, but that is also situational and doesn't cost must as it's just a few vertices simulated.
The hair simulation, however, does cost a fair bit. I already have card hair ready to replace the strand based hair for lower graphics settings. While it of course can't compete with strand based hair visually, it does eliminate the highly demanding hair simulation and rasterization. Only thing left is making a system that can switch between those styles on demand.
I'm constantly profiling the program to check for bottlenecks. Also I'm profiling the graphics using several tools to identify bottlenecks there as well, but it is very complicated work, as unless you did something completely wrong, there usually aren't any obvious things.
I spent the last week to optimize the mesh of all characters. I made a system that automatically batches body parts into one mesh, combining UVs (there are 5 for different systems in the background), and textures into atlases. Something that is simple for normal static objects, but incredibly complicated for as complex as the girl models are. And I want to always ensure backwards compatibility, so I can go back, and make changes to the model itself in blender, and don't have to spend a week setting everything up again, so I always ensure that my own pipeline is automatic in workflow.
The main reason for keeping a clean compatible system like this is that I'm just a single dev. I can't afford to hire a team of artists to create the models and texture in an already optimized state. I'm already spending a lot of money on different things for the game in commissions, but a dedicated artist would be on another level, especially since a single one would not be enough at the pace I'm moving. So I have to rely on being able to use assets from other sources, just like I would for a Daz3d/HS game in RenPy etc. However, should I ever get there, I would definitely make good use of a team.
Optimization as a word is in itself very vague, as it's nature is highly dependent on the environment and circumstances. Unless a major mistake is made, it's not straight forward at all.
As an example, optimization could be just taking away an option to crank a setting up to a value that only marginally looks better but exponentially needs more performance. And even though the system behind that setting is optimized, doing too much of it will cause issues on the newest graphics cards.
Then there is also, as mentioned above, workflow. Real optimization often entails combining things or doing things at the same time, while stripping off parts that aren't necessary or managing the back-end by buffering.
Not only is it complicated, it also can negatively affect the workflow. For example, if I were just to manually combine my meshes, I could no longer go back and make texture changes without having re-setup the whole thing. Doing it manually would be a lot faster at first, but it will eventually come back and bite you in the ass. And that not only is true for optimization but general workflow.
