[GH-ISSUE #38] performance issues with wildcards #28

New issue

Closed

opened 2026-10-30 21:17:21 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-30 21:17:21 +00:00

Owner

Originally created by @djkacevedo on GitHub (Oct 24, 2022).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/38

Originally assigned to: @DominikDoom on GitHub.

With a lot of wildcards performance drops massively.

I got it turned off for now, and works fine with regular tags.

I'm using the wildcards from the dump on https://rentry.org/sdupdates so 483.

More than a dozen slows things down, more than a couple hundred makes the webui unusable.

Originally created by @djkacevedo on GitHub (Oct 24, 2022). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/38 Originally assigned to: @DominikDoom on GitHub. With a lot of wildcards performance drops massively. I got it turned off for now, and works fine with regular tags. I'm using the wildcards from the dump on https://rentry.org/sdupdates so 483. More than a dozen slows things down, more than a couple hundred makes the webui unusable.

bsakaguchi closed this issue

2026-10-30 21:17:21 +00:00

bsakaguchi commented

2026-10-30 21:17:22 +00:00

Author

Owner

@DominikDoom commented on GitHub (Oct 24, 2022):

I've reproduced the issue with those tags, I'll see what I can do about it.

@DominikDoom commented on GitHub (Oct 24, 2022): I've reproduced the issue with those tags, I'll see what I can do about it.

bsakaguchi commented

2026-10-30 21:17:23 +00:00

Author

Owner

@DominikDoom commented on GitHub (Oct 24, 2022):

I think I found the issue:
Despite the total number of wildcards being much less than the number of tags, it caused substantial memory issues due to how they were stored. Currently, I match files to their contents with a typical key-value structure, which seems to be the issue here.

I changed wildcards to be loaded on demand instead of pre-matched to their respective files, so I could store them without keys. This makes it take minimally longer for small wildcard file counts since they're not preloaded, but it's barely noticeable and fixes the loading & performance issues for large amounts.

@DominikDoom commented on GitHub (Oct 24, 2022): I think I found the issue: Despite the total number of wildcards being much less than the number of tags, it caused substantial memory issues due to how they were stored. Currently, I match files to their contents with a typical key-value structure, which seems to be the issue here. I changed wildcards to be loaded on demand instead of pre-matched to their respective files, so I could store them without keys. This makes it take minimally longer for small wildcard file counts since they're not preloaded, but it's barely noticeable and fixes the loading & performance issues for large amounts.