[manio]

Hi Lars,
As you may know I am planning to work on incremental epg updates patch. I have a big channel list with xvdr (it's good for testing, because even small regressions scales very visible).
From some time I've discovered that channel loading is very slow (utilizing 100% of my CPU when xmbc is starting). By the way working on incremental EPG PR I found some interesting conclusions (i also bisected a little and I'd like to share with you what i found out):

Firstly: important data. Channels count:
$ wc -l channels.conf
5575 channels.conf

* saving EPG database disabled
* CPU: Athlon II X4 630
* OS: Linux (x86_64)

Of course I did all test with the above configuration and same channel count to have reliable results.

Long long time ago (before commit: '980bde5 pvr: cleanups in CPVRChannel') loading channels and EPG data was really quick:
It took even 9 seconds which was really great result!!

Currently in mainline xbmc (231d8e0) it took 74 seconds

Things went wrong starting from commit '980bde5 pvr: cleanups in CPVRChannel'. I discovered that the big problem introduced there was a critical sections (If i checked out to that commit and disabled all introduced critical sections then initializing also took 9 sec.
In '40e6ccf pvr: use a boost:hared_ptr for CPVRChannel' a overhead was related with switching to shared_ptr and also with introduced sorting in CPVRChannelGroupInternal::UpdateFromClient()
When I disabled creating critical sections and this sorting+renumbering then I've got 23 seconds loading-time.

Finally I was trying to reducing loading time on mainline xbmc. Here are the results:
without any patch: 74 sec

after getting rid of CSingleLock in CPVRChannel::UniqueID(void):
54 sec

after getting rid of all CSingleLocks in CPVRChannel introduced in 980bde5:
46 sec

disabling channel sorting (i know it is a feature which cannot be disabled, but maybe optimised, eg sorting once at the end, and not on every new internal group member)

Code:

diff --git a/xbmc/pvr/channels/PVRChannelGroupInternal.cpp b/xbmc/pvr/channels/PVRChannelGroupInternal.cpp
index f2651c6..c0fc118 100644
--- a/xbmc/pvr/channels/PVRChannelGroupInternal.cpp
+++ b/xbmc/pvr/channels/PVRChannelGroupInternal.cpp
@@ -99,11 +99,11 @@ void CPVRChannelGroupInternal::UpdateFromClient(const CPVRChannel &channel, unsi
     m_members.push_back(newMember);
     m_bChanged = true;
.
-    if (m_bUsingBackendChannelOrder)
+/*    if (m_bUsingBackendChannelOrder)
       SortByClientChannelNumber();
     else
       SortByChannelNumber();
-    Renumber();
+    Renumber();*/
   }
}

result: 22 sec
Last result is still far from the best 9 seconds, but it's better then waiting over a minute
Maybe nothing can be done (i know that critical sections are important for threadsafe) but maybe I've inspired you for some improvement in this area anyway

regards!

[jajoflo]

hum, I really did not had the time to investigate but what I did was simply to refresh less often (Sleep longer). The ugly hack should be remove, but for now.

------------------ xbmc/pvr/windows/GUIWindowPVRChannels.cpp ------------------
index c804f68..9f4d235 100644
@@ -608,6 +608,6 @@ void CGUIWindowPVRChannels:rocess(void)
iCount = 0;
SetInvalid();
}
- Sleep(50);
+ Sleep(5000);
}
}

[opdenkamp]

thanks for investigating this. I'll have a look at fixing this properly.