2012-09-14, 23:46
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)
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!
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!