home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Using reflection for GUIControlFactory
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="NoMoDo" data-source="post: 4218" data-attributes="member: 10381"><p>Sorry, I didn't make myself clear.</p><p></p><p>First, I am referring of course only to #1, startup\loading time. </p><p>Second, I did do profiling, I wasn't speculating, I just wasn't sure if I should rely on only one profiling tool. </p><p></p><p>As I mentioned in my first post, I used <a href="http://nprof.sourceforge.net" target="_blank">NProf</a>, which seems to be a very thorough and accurate tool for measuring the relative duration the program spends in each of function. It starts measuring when you start the program, and stops when you exit. To profile the change to GUIControlFactory, I profiled only by opening MP, and then immediately closing it when the Home plugin appeared.</p><p></p><p>I think it's also a fair speculation that the creation of many many short-term GUI reference controls took its toll on the GC (my method doesn't make any reference controls - it keeps the reference nodes themselves in a Hashtable instead and updates the reference data to the controls directly.)</p><p></p><p>Now, here are the actual numbers from NProf (For loading MP with Metal skin, and closing as soon as Home appears):</p><p>The results presented here are from a single test (not averages), but I've conduct the test quite a few times before and got (more or less) the same numbers.</p><p></p><p><strong>Before (With old GUIControlFactory)</strong></p><p>Calls to GUIWindow::LoadSkin(): 15</p><p>% of total execution time in all threads: 43.72%</p><p></p><p>in which -></p><p></p><p>Calls to GUIControlFactory::Create: 228</p><p>% of total execution time in all threads: 37.54%</p><p></p><p>in which -></p><p></p><p>Calls to GUIControlFactory::GetString: 15190</p><p>% of total execution time in all threads: 17.99%</p><p></p><p>Calls to GUIControlFactory::GetInt: 12495</p><p>% of total execution time in all threads: 14.50%</p><p></p><p>etc...</p><p></p><p></p><p></p><p><strong>After (with the rewritten GUIContrlFactory</strong></p><p>Calls to GUIWindow::LoadSkin(): 16</p><p>% of total execution time in all threads: 7.74%</p><p></p><p>in which -></p><p></p><p>Calls to GUIControlFactory::Create: 228</p><p>% of total execution time in all threads: 2.22%</p><p></p><p></p><p></p><p><strong>Analysis:</strong></p><p>As we can see the GUIControlFactory class is responsible for approximatly 37% of the loading time in MP, creating a serious bottleneck. The main reason for this performance bottleneck was tens of thousands of unnecessary calls to the various Get functions which attempted to retrieve data from the XML node. My method eliminates this problem by stepping over the xml nodes and retrieving valid data where it can be found, so the maximum amount of calls to the data retrieval function is the number of valid elements in the reference control + the number of valid elements in the control node itself. This way, checking wether the data is actually there is also unnecessary.</p></blockquote><p></p>
[QUOTE="NoMoDo, post: 4218, member: 10381"] Sorry, I didn't make myself clear. First, I am referring of course only to #1, startup\loading time. Second, I did do profiling, I wasn't speculating, I just wasn't sure if I should rely on only one profiling tool. As I mentioned in my first post, I used [url=nprof.sourceforge.net]NProf[/url], which seems to be a very thorough and accurate tool for measuring the relative duration the program spends in each of function. It starts measuring when you start the program, and stops when you exit. To profile the change to GUIControlFactory, I profiled only by opening MP, and then immediately closing it when the Home plugin appeared. I think it's also a fair speculation that the creation of many many short-term GUI reference controls took its toll on the GC (my method doesn't make any reference controls - it keeps the reference nodes themselves in a Hashtable instead and updates the reference data to the controls directly.) Now, here are the actual numbers from NProf (For loading MP with Metal skin, and closing as soon as Home appears): The results presented here are from a single test (not averages), but I've conduct the test quite a few times before and got (more or less) the same numbers. [b]Before (With old GUIControlFactory)[/b] Calls to GUIWindow::LoadSkin(): 15 % of total execution time in all threads: 43.72% in which -> Calls to GUIControlFactory::Create: 228 % of total execution time in all threads: 37.54% in which -> Calls to GUIControlFactory::GetString: 15190 % of total execution time in all threads: 17.99% Calls to GUIControlFactory::GetInt: 12495 % of total execution time in all threads: 14.50% etc... [b]After (with the rewritten GUIContrlFactory[/b] Calls to GUIWindow::LoadSkin(): 16 % of total execution time in all threads: 7.74% in which -> Calls to GUIControlFactory::Create: 228 % of total execution time in all threads: 2.22% [b]Analysis:[/b] As we can see the GUIControlFactory class is responsible for approximatly 37% of the loading time in MP, creating a serious bottleneck. The main reason for this performance bottleneck was tens of thousands of unnecessary calls to the various Get functions which attempted to retrieve data from the XML node. My method eliminates this problem by stepping over the xml nodes and retrieving valid data where it can be found, so the maximum amount of calls to the data retrieval function is the number of valid elements in the reference control + the number of valid elements in the control node itself. This way, checking wether the data is actually there is also unnecessary. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Using reflection for GUIControlFactory
Contact us
RSS
Top
Bottom