A1111 doesn't show the full range that the LoRA developer gave

[SolemAubrey]

I've tried using lora:[Name]:[weight] with a single LoRA and found myself encountering performance problems. At certain values that should be supported, A1111 either hangs forever or starts causing my whole PC to freeze. Just to be clear, I do not put the name and weight in square brackets. I only use the square brackets here to indicate a proper value needs to be inserted into that placeholder.

I looked at editing the metadata and saw that you could set a preferred weight there, but from within the metadata I am only given a fraction of the range that the LoRA developer intended the LoRA to have. The LoRA is supposed to work with positive and negative weights, but the metadata only gives me options from 0 - 2.

I highly doubt that if there was a way to override the scale given by the metadata and set my preferred weight to a negative value, that doing so would suddenly cause the LoRA to work as intended. Nevertheless, I have to ask for help understanding why this situation is occurring. The LoRA works on civitai just fine, but not in A1111.

I've tried asking the LoRA developer for clarification, too, but have not been met with a timely response.

[w-e-w]

I highly doubt that if there was a way to override the scale given by the metadata and set my preferred weight to a negative value,

welll you highly doubt incorrectly, overriding UI elements is a feature by design
it's kind of the whole point of ui-config.json

in this case in ui-config.json change thise values whatever you want

    "txt2img/Preferred weight/minimum": 0.0,
    "txt2img/Preferred weight/maximum": 2.0,
    "img2img/Preferred weight/minimum": 0.0,
    "img2img/Preferred weight/maximum": 2.0,

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/User-Interface-Customizations#ui-element-dafault-value-and-range-limit-step-size

[w-e-w]

what lora are you using?

[SolemAubrey]

I am going to mark this as solved, even though fixing the metadata limits has no impact on performance. I accept that my setup struggles much more with some of these LoRAs applied, but if left alone it eventually completes the task assigned. So it's on me to upgrade to better hardware if I want to run these LoRAs less painfully.

[w-e-w]

I really can't imagine why certain weights of lora would cause performance issues
if you wish to actually get into the details on what is causing the issue
then I think the only solution is to ask you to do some profiling

profiling basically means generate a detailed report of what's going on the execution including including the time that it takes to perform each function call

if you are using dev branch then you could enable profileing under setings Profiler
Enable profiling and select both CPU and CUDA
apply the setting do one generation
perform two image generation one with the vaules that causes slow down and one without
save the trace.json after EACH generation and uploads them so we can analyze the

if however if you're not on the dev branch
use my extention https://github.com/w-e-w/sd-webui-profiler
and same as above perform two image generation one with the vaules that causes slow down and one without

the extention saves traces at different locations, it is saved under sub-folders under extentions/sd-webui-profiler/traces/

note if I recall correctly the trace file is quite large and you won't be able to upload them directly on hear

[SolemAubrey]

It was a combination of problems. I wasn't using the correct code originally (e.g. I didn't even use lora: at first, only <[name]:[strength]>). My nonsense prompts, at best, got ignored and it proceeded without using the LoRA. Uploading those results to civitai I could see the LoRA wasn't detected, which proves to me it wasn't used.

When I finally did sort that out, I thought something was wrong because I couldn't do anything else like I could before (e.g. even my mouse cursor position would not display movement normally). The performance issue isn't limited to certain weights. It's limited to whether I use the LoRA or not. And I'm on old hardware (1080 card; barely 6 GB VRAM available), so I'm not surprised.

I expected A1111 to perform basically the same way with and without the LoRA, and that impatience only created more problems, as I basically gave up without giving it enough time to run.

[w-e-w]

Uploading those results to civitai I could see the LoRA wasn't detected, which proves to me it wasn't used

you know we list the info for you to see right
the reason that civitai knows what is used is becuase of the smae info

---

I expected A1111 to perform basically the same way with and without the LoRA, and that impatience only created more problems, as I basically gave up without giving it enough time to run.

normally that should be the case
there is some extra computation that needs to be done when lora is used but it should be negligible

but if you're unlucky enough that the extra bit of lora stuff pushes your vram usage over the edge you could experience massive performance slowdown (assuming that it doesn't run out of vram and crash)
#11063

I'm not saying this is what's happening I'm just saying that this is a possibility

also assuming that you're running your display off your 1080 card (which should be most people) all the applications and rendering of your display may take up some vram as well, this means that you don't actually have the full 6GB (worst the vram usage it's not even consistent), 6GB is already pretty low for stable diffusion depending on what you're doing