Bug 95077 - IRC: Joining large channels is slow when many users are Op, Voice, or Away.
Summary: IRC: Joining large channels is slow when many users are Op, Voice, or Away.
Status: RESOLVED WORKSFORME
Alias: None
Product: kopete
Classification: Applications
Component: IRC Plugin (show other bugs)
Version: 0.9.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-13 16:38 UTC by Joseph Vigneau
Modified: 2018-11-02 22:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Vigneau 2004-12-13 16:38:01 UTC
Version:           0.9.1 (using KDE KDE 3.3.1)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) 
OS:                Linux

When joining a large channel in IRC (such as #gentoo on irc.freenode.net, which has over 500 people at the time of this writing), Kopete spends a lot of time populating the user list, and putting "<user> is Op", and "<user> is Away" messages into the chat window.  As a result, the CPU is pegged at 100% for up to 20 seconds (P4 2.6GHz) while the list is populated.

It would be very nice if the sorting was done without the user watching the list build, and it would also be nice if the Op/Away/Voice messages were not displayed when the channel is joined.
Comment 1 Richard Smith 2004-12-14 01:36:20 UTC
On Monday 13 December 2004 15:38, Joseph Vigneau wrote:
> It would be very nice if the sorting was done without the user watching the
> list build

I fixed this in CVS a couple of weeks ago.

> and it would also be nice if the Op/Away/Voice messages were 
> not displayed when the channel is joined.

I got some of the way towards fixing this. Don't remember whether I committed 
it or whether I've got a patch here going stale, but I got rid of all but the 
Away messages.
Comment 2 Joseph Vigneau 2004-12-14 03:30:43 UTC
Very cool.  Thanks for taking a look at this!
Comment 3 Jason Keirstead 2005-01-20 03:41:15 UTC
CVS commit by brunes: 

Make joining a channel non-blocking again, basically reverting richard's commit of Nov 4th.

Until we have truely async adding of contacts to the manager, and the ability to add contacts
in batches to speed things up and have less resorts, this hack will need to remain in place.
Better to have a bit slower overall joining of a large channel, thean to have it block the whole
GUI for tens of seconds.

Note this does not in any way fix this bug, but at least the GUI is no longer blocked while
this channel join is in place.

CCMAIL: 95077@bugs.kde.org


  M +14 -7     ircchannelcontact.cpp   1.119
  M +1 -0      ircsignalhandler.cpp   1.13


--- kdenetwork/kopete/protocols/irc/ircchannelcontact.cpp  #1.118:1.119
@@ -40,4 +40,9 @@
 #include <qtimer.h>
 
+//This is the number of nicknames we will process concurrently when joining a channel
+//Lower numbers ensure less GUI blocking, but take marginally longer to complete.
+//Higher numbers are absolute fastest, but block GUI until all members are added
+#define NICK_BATCH_LENGTH 1
+
 IRCChannelContact::IRCChannelContact(IRCContactManager *contactManager, const QString &channel, Kopete::MetaContact *metac)
         : IRCContact(contactManager, channel, metac, "irc_channel")
@@ -160,6 +165,5 @@ void IRCChannelContact::namesList(const 
 {
         mInfoTimer->stop();
-        mJoinedNicks += nicknames;
-        if (mJoinedNicks.count() == nicknames.count())
+        mJoinedNicks = nicknames;
                 slotAddNicknames();
 }
@@ -167,4 +171,5 @@ void IRCChannelContact::namesList(const 
 void IRCChannelContact::endOfNames()
 {
+        setMode(QString::null);
         slotUpdateInfo();
 }
@@ -172,7 +177,6 @@ void IRCChannelContact::endOfNames()
 void IRCChannelContact::slotAddNicknames()
 {
-        if (!manager(Kopete::Contact::CannotCreate) || mJoinedNicks.isEmpty())
+        if( !manager(Kopete::Contact::CannotCreate) || mJoinedNicks.isEmpty())
         {
-                setMode(QString::null);
                 return;
         }
@@ -180,5 +184,5 @@ void IRCChannelContact::slotAddNicknames
         IRCAccount *account = ircAccount();
 
-        while (!mJoinedNicks.isEmpty())
+        for( uint i = 0; !mJoinedNicks.isEmpty() && i < NICK_BATCH_LENGTH; ++i )
         {
                 QString nickToAdd = mJoinedNicks.front();
@@ -187,5 +191,4 @@ void IRCChannelContact::slotAddNicknames
                         nickToAdd = nickToAdd.remove(0, 1);
 
-                mJoinedNicks.pop_front();
                 IRCContact *user;
 
@@ -206,5 +209,9 @@ void IRCChannelContact::slotAddNicknames
                 else if( firstChar == '+')
                         manager()->setContactOnlineStatus( static_cast<Kopete::Contact*>(user), m_protocol->m_UserStatusVoice );
+
+                mJoinedNicks.pop_front();
         }
+
+        QTimer::singleShot( 0, this, SLOT( slotAddNicknames() ) );
 }
 


Comment 4 Richard Smith 2005-01-21 00:48:48 UTC
On Thursday 20 January 2005 02:41, Jason Keirstead wrote:
> Make joining a channel non-blocking again, basically reverting richard's
> commit of Nov 4th.
>
> Until we have truely async adding of contacts to the manager, and the
> ability to add contacts in batches to speed things up and have less
> resorts, this hack will need to remain in place. Better to have a bit
> slower overall joining of a large channel, thean to have it block the whole
> GUI for tens of seconds.

I disagree - better to be in the channel after fifteen, maybe twenty seconds 
than still be waiting for it to load, pretty much making Kopete unusably 
slow, for well over ten minutes. But do what you like.
Comment 5 Jason Keirstead 2005-02-17 03:49:30 UTC
Users will no longer have status changes to Op or Voice. The Away is stilla problem though, because this is actually returned by the WHOIS that happens after the channel is done being joined.
Comment 6 Andrew Crouthamel 2018-11-02 04:22:51 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Joseph Vigneau 2018-11-02 12:15:53 UTC
It's been nearly fourteen years since I filed this bug, and I'm no longer in a position where I can realistically re-test this issue (I haven't used KDE in over twelve years).  Moving this back to the REPORTED state as requested.
Comment 8 Andrew Crouthamel 2018-11-02 22:33:11 UTC
Thanks for the update!