Closed Bug 954618 Opened 10 years ago Closed 10 years ago

Severe pauses/hang when dealing with large conversation backlogs

Categories

(Instantbird Graveyard :: Conversation, defect)

x86
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: florian)

References

Details

*** Original post on bio 1187 by Kevin Gadd <kevin.gadd AT gmail.com> at 2011-11-27 12:57:00 UTC ***

If a conversation window is left open for a day or more in an active channel, the backlog becomes quite large. When dealing with large chat backlogs, Instantbird's performance begins to degrade in various areas:

Using Ctrl-F find in a long chatlog will hang the process for a long (if not infinite) period of time.
Closing a chat window and then reopening it later will hang the process for a while (depending on the length of the chatlog) while it repopulates the window. One or more 'this script is taking too long, stop/continue' XUL dialogs may appear during this process.
Instantbird's memory usage also increases dramatically as the size of a chat backlog increases. Presumably a long enough backlog would eventually result in either address space exhaustion or memory exhaustion, but I've yet to leave it running for more than a couple days in order to confirm this.

Furthermore, because the hangs resulting from this problem occur on the UI thread, if Instantbird remains hung long enough, network connections to chat servers will time out, causing a reconnect.


A couple ideas for solutions:

Use Instantbird's built in support for logging conversations as the conversation backlog as well. Load the log file into the conversation backlog in order to populate the window, so that Gecko's async loading support for HTML can be used to avoid blocking the main thread. You can still dynamically add new conversation text a line or two at a time to the document once it's been loaded, to mirror the log.

You could also begin omitting earlier sections of the backlog once it reaches a certain size to ensure that operations like Find don't hang the UI, and keep memory usage under control.
*** Original post on bio 1187 by Kevin Gadd <kevin.gadd AT gmail.com> at 2011-11-27 13:02:31 UTC ***

For reference, with 2 days of chat history in two medium-traffic (~50 users average, ~150 users average), InstantBird is currently using 250MB of memory and 300MB of address space.

If I close and then reopen the chat window for the larger channel, InstantBird's UI thread hangs for around 2-3 minutes while repopulating the backlog.
*** Original post on bio 1187 at 2011-11-27 17:11:32 UTC ***

It hangs for *minutes*? Wow! I spent a few hours today profiling this because I'm annoyed by the unresponsiveness (of 1 to 10 seconds) when I reopen a large conversation with thousands of messages.
I've never seen it be bad enough to show the "this script is taking too long" XUL dialog, except maybe when the machine was out of memory because of virtual machines running and had swapped Instantbird's memory off to disk.

Also, I've very rarely seen the Instantbird process take more than 200MB of RAM.

I'm wondering what makes it an order of magnitude slower for you. Do you have a slow machine? Very limited available RAM? Or maybe a specific messages theme that would need more memory?
*** Original post on bio 1187 by Kevin Gadd <kevin.gadd AT gmail.com> at 2011-11-27 20:10:54 UTC ***

I'm using the Paper Sheets theme, maybe it's complex enough to cause the DOM stuff that populates the backlog to get a lot slower. I'll try a different theme.

My machine is maybe two years old now, but it was a high end development machine when I got it. Core i7, 3.3ghz. Should be fast enough to be able to populate the backlog. RAM definitely isn't a problem, I have 12GB of it.
*** Original post on bio 1187 at 2011-11-27 22:14:56 UTC ***

Paper Sheets isn't terribly complex (it's simpler than Bubbles that I'm using).

And that machine definitely isn't a slow one. I was wondering if maybe you were on a netbook :).

You may just be having larger backlogs than I do then. Mine tend to not contain more than a week worth of messages as I'm using nightly builds, and so I restart Instantbird everyday for the update.

Do the conversations you reopen typically contain almost only unread messages, or rather contain mostly already displayed messages + a few new ones which are the one you actually want to see? I'm wondering if limiting the number of context messages that are redisplayed (bug 954549 (bio 1116)), which is quite easy to do, would help in your case.

Obviously, we also want to optimize this and make it asynchronous, but if there's an easy win that could relieve the pain, we should do that quickly first.

Using the logs as a way to populate the back logs (and the search results) is also something we intend to do. The current log format is unfortunately impossible to use for that, so we are going to change it soon for something easier to parse.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Original post on bio 1187 at 2011-11-27 22:16:20 UTC ***

A couple aspects of this were already on file, so just referencing them here.

(In reply to comment #0)
> If a conversation window is left open for a day or more in an active channel,
> the backlog becomes quite large. When dealing with large chat backlogs,
> Instantbird's performance begins to degrade in various areas:
> 
> Using Ctrl-F find in a long chatlog will hang the process for a long (if not
> infinite) period of time.
This is bug 954573 (bio 1140) (which you already filed).

> Closing a chat window and then reopening it later will hang the process for a
> while (depending on the length of the chatlog) while it repopulates the window.
This is essentially bug 954549 (bio 1116).

> Use Instantbird's built in support for logging conversations as the
> conversation backlog as well. Load the log file into the conversation backlog
> in order to populate the window, so that Gecko's async loading support for HTML
> can be used to avoid blocking the main thread. You can still dynamically add
> new conversation text a line or two at a time to the document once it's been
> loaded, to mirror the log.
> 
> You could also begin omitting earlier sections of the backlog once it reaches a
> certain size to ensure that operations like Find don't hang the UI, and keep
> memory usage under control.
Yes, this is essentially the solution that we would like, but the logging that is done on conversations currently loses data, so it can't fully rebuild a conversation.
*** Original post on bio 1187 at 2011-12-07 09:39:46 UTC ***

Note: this bug is about the slowness of (re)displaying a large number of messages. For the slowness of large lists of participants in IRC rooms (typically #ubuntu), see bug 953721 (bio 276).
*** Original post on bio 1187 at 2012-03-22 10:07:36 UTC ***

Messages are now added in chunks (which shouldn't take much more than 40ms) to allow the UI to update frequently. Additionally a progressbar is shown at the bottom of the conversation until all messages are loaded. 

This landed at end of december 2011 already:

http://hg.instantbird.org/instantbird/rev/723214af0fff
*** Original post on bio 1187 by Miika Ahonen <miika.ahonen AT gmail.com> at 2012-06-07 22:11:26 UTC ***

Solving bug 953744 (bio 301) would also help with this a fair bit I'd think.
*** Original post on bio 1187 at 2012-08-10 09:47:57 UTC ***

Btw Papersheets is an incredibly slow message style (comment #4 is wrong on that score).
*** Original post on bio 1187 at 2013-04-23 16:55:30 UTC ***

(In reply to comment #0)
> If a conversation window is left open for a day or more in an active channel,
> the backlog becomes quite large. When dealing with large chat backlogs,
> Instantbird's performance begins to degrade in various areas:
> 
> Using Ctrl-F find in a long chatlog will hang the process for a long (if not
> infinite) period of time.
This is bug 954573 (bio 1140).

> Closing a chat window and then reopening it later will hang the process for a
> while (depending on the length of the chatlog) while it repopulates the window.
> One or more 'this script is taking too long, stop/continue' XUL dialogs may
> appear during this process.
This aspect was fixed in http://hg.instantbird.org/instantbird/rev/723214af0fff

> Instantbird's memory usage also increases dramatically as the size of a chat
> backlog increases. Presumably a long enough backlog would eventually result in
> either address space exhaustion or memory exhaustion, but I've yet to leave it
> running for more than a couple days in order to confirm this.
This should be easier to diagnose with about:memory.

> Furthermore, because the hangs resulting from this problem occur on the UI
> thread, if Instantbird remains hung long enough, network connections to chat
> servers will time out, causing a reconnect.
There isn't anything we can do about this.

> Use Instantbird's built in support for logging conversations as the
> conversation backlog as well. Load the log file into the conversation backlog
> in order to populate the window, so that Gecko's async loading support for HTML
> can be used to avoid blocking the main thread. You can still dynamically add
> new conversation text a line or two at a time to the document once it's been
> loaded, to mirror the log.
We don't store logs in HTML, it's a poor format for storing conversation information.

> You could also begin omitting earlier sections of the backlog once it reaches a
> certain size to ensure that operations like Find don't hang the UI, and keep
> memory usage under control.
This is bug 953744 (bio 301) / bug 955007 (bio 1577).

I'm going to close this issue as I think the various parts are covered by different bugs. If there are specific issues not yet filed we should open specific bugs that are clearly fixable for them.
Assignee: nobody → florian
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.2
You need to log in before you can comment on or make changes to this bug.