Bug #807
Hang on ignore list change
0%
Description
Monoclient 0.5-rc1+62 git-64e5ca6
Monoclient 0.5-rc1+65 git-0918ccf
Program unresponsive and CPU usage around 90% for 30 seconds or more when confirming a change to ignore list.
Happens with ten or more existing ignore list entries.
Using SQLite db < 2mb, but doesn't seem to be any abnormal disk activity during hanging/cpu hogging. Duration of hanging does seem to correlate with buffer length, tho.
WinXP SP3 600MHz 2GB RAM
History
#1 Updated by seezer over 15 years ago
- Category set to Quassel Client
- Status changed from New to Assigned
- Assignee set to seezer
- OS changed from Windows to Any
This is bad news.
Storing the changes in the database shouldn't be the reason here. The amout of data is just not that big.
The actual problem is probably that quassel refreshes every existing chatview (a chatview is created when you click on a channel/query the first time). That definately is some work your relatively slow machine might have problems with.
Also i'd expect the amount of active chatviews to make the difference, not the buffer content, as i think only the actual shown data in a chatview is refreshed.
So I see two solutions here:
Either I can get that updating tuned so that it's not a problem for anyone anymore, or we need a setting to disable the dynamic refreshing.. hope we don't need the latter..
Will look into it.
#2 Updated by fen over 15 years ago
I normally run underclocked. At full 2GHz CPU, adding, toggling, or removing an ignore list entry with enough buffer backlog loaded for Quassel to use 16MB of memory (from 8MB at startup) still hangs the program for about 50 seconds. Doing so with minimal buffer backlog loaded (about 400 lines total) only hangs for a couple of seconds or not at all. This is with the same 8 buffers.
#3 Updated by seezer over 15 years ago
fen wrote:
I normally run underclocked. At full 2GHz CPU, adding, toggling, or removing an ignore list entry with enough buffer backlog loaded for Quassel to use 16MB of memory (from 8MB at startup) still hangs the program for about 50 seconds. Doing so with minimal buffer backlog loaded (about 400 lines total) only hangs for a couple of seconds or not at all. This is with the same 8 buffers.
And you did create a chatview for all of them before testing with fewer lines?
Anyway, i have one patch ready that isn't yet included upstream. That should help already. Will check if there are other problems.
You could grab the patch from my git repository if you want.
#4 Updated by seezer over 15 years ago
Now included upstream in commit e7075c71.
Please tell me how that works for you.
#5 Updated by fen over 15 years ago
Just delays the pain until switching channels. Being able to limit the amount of backlog in memory at any given time would help somewhat, but in the end the only real fix is to make updating the chat view hog less of the processor. I assume this isn't a problem on Linux? Have any other Win users reported something like this?
#6 Updated by seezer almost 15 years ago
- Status changed from Assigned to Feedback
- Version changed from 0.5-pre to 0.5-rc2
Is this still valid?
We do have some delay in switching channels but that is true even if you don't have any active ignore rules.
But it definitely shouldn't take more than 1-2 seconds.
#7 Updated by johu over 14 years ago
- Status changed from Feedback to Closed
- Version changed from 0.5-rc2 to 0.5.0
No feedback was given within 6 months.