6.0RC1 user interface speed
Forum rules
Help us help you:
Help us help you:
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
6.0RC1 user interface speed
Why is the UI so much slower than the 0.5 versions? Is this something that is being addressed? I have 117 filters and my computer bogs down like it's computing PI whenever I try to edit the filter list.
Re: 6.0RC1 user interface speed
The UI isn't slower.
Re-evaluating the filters against the feed content takes time. 0.5.6 didn't do that.
117 filters is a bit extreme.
Evaluating 117 regular expressions against (maybe) a large number of titles is time consuming.
There's room for improvement, but priority now is on ironing out functional bugs.
Re-evaluating the filters against the feed content takes time. 0.5.6 didn't do that.
117 filters is a bit extreme.
Evaluating 117 regular expressions against (maybe) a large number of titles is time consuming.
There's room for improvement, but priority now is on ironing out functional bugs.
Re: 6.0RC1 user interface speed
I have done a few tests.
There's a simple optimization possible in the test, which should reduce it noticeably.
However the true performance killer is in the size of the HTML code generated.
The dropdown menu for the queue order grows quadratically with the amount of filters.
So 10 filters give 100 lines of HTML code, but 100 filters will give 10.000 lines.
I tried with 120 filters, the time to generate the resulting 2.5MByte of HTML is longer than the actual filtering takes
I'll tackle this issue for the next release.
There's a simple optimization possible in the test, which should reduce it noticeably.
However the true performance killer is in the size of the HTML code generated.
The dropdown menu for the queue order grows quadratically with the amount of filters.
So 10 filters give 100 lines of HTML code, but 100 filters will give 10.000 lines.
I tried with 120 filters, the time to generate the resulting 2.5MByte of HTML is longer than the actual filtering takes
I'll tackle this issue for the next release.