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!)
Performance suggestion
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="ojo" data-source="post: 3058" data-attributes="member: 10402"><p>Hi all,</p><p></p><p>nice going, this is by far the greatest of HTPC products available.... And open source.</p><p></p><p>I myself being a software developer in a Danish telecom, was eager to check out the product and have a look at some code. Doing so i stumbled upon a performance suggestion.</p><p></p><p>Given the impressive number of plug-in already done, and planned for release 1.0, I would suspect that most of us won't use 100% of all the plug-ins all the time. I'd say that 50%-80% would be a common ground, and some of us might even settle with as little as 25% of the plug-ins.</p><p></p><p>Checking the code and load time of the MP though suggests that 50% of the loadtime is used to fire up the plug-ins by the PlugInManager. So dwelling on that i came up with this suggestion.</p><p></p><p>F.x. the [bold]LoadWindowPlugins[/bold] method doesn't know if a given plug-in is enabled or not. The problem is due to the plugin design. Only the plug-in itself knows its name. This would be ok, if it wasn't for the fact that the plugin doesn't have to be enabled, but the MediaPortal.xml (settings) doesn't know about that before instantiating and getting the plug-in name. In other words, all plug-in are loaded regardless of their usage. </p><p></p><p>This wouldn't be a problem if the .NET CLR/Framework supported a way to get rid of the unwanted (only in this case) plug-ins. But since there is no Assembly.Unload() method and the loading of the assembly takes up a lot of I/O, JIT compilation, memory allocation and so forth, calling the Assembly.Load(...) should be avoided for non-enabled plug-ins at all.</p><p></p><p>I've tried to do an investigation and changed some of the code to comply with that. Given the fact that the Setup/Configuration program must use all plug-ins and that is able to reference the plug-in name with the assembly name if suggest that the MediaPortal.xml could be extended like this.</p><p></p><p>[code]</p><p> <section name="plugins"></p><p> <entry name="My Alarm">no</entry></p><p>...</p><p> <entry name="Winamp">no</entry></p><p> </section></p><p> <section name="plugindlls"></p><p> <entry name="GUIAlarm.dll">My Alarm</entry></p><p>...</p><p> </section></p><p></p><p>[/code]</p><p></p><p>Given this the PluginManager would be able to scan the directory, for every assembly, get the plug-in name and check to see if the plug-in is enabled BEFORE loading.</p><p> </p><p>The code below uses the above structure.</p><p></p><p>[code]</p><p></p><p> static public void LoadWindowPlugins()</p><p> {</p><p> System.IO.Directory.CreateDirectory(@"plugins");</p><p> System.IO.Directory.CreateDirectory(@"plugins\windows");</p><p> string [] strFiles=System.IO.Directory.GetFiles(@"plugins\windows", "*.dll");</p><p> foreach (string strFile in strFiles)</p><p> {</p><p> if (PlugInEnabled2(strFile)) </p><p> {</p><p> LoadWindowPlugin(strFile);</p><p> }</p><p> }</p><p></p><p> LoadWindowPlugin("Dialogs.dll");</p><p> }</p><p></p><p>...</p><p></p><p> static public bool PlugInEnabled2(string strDllname)</p><p> {</p><p> using (AMS.Profile.Xml xmlreader=new AMS.Profile.Xml("MediaPortal.xml"))</p><p> {</p><p> // from the assembly name check the reference to plugin name</p><p> // if available check to see if the plugin is enabled</p><p> // if the plugin name is unknown suggest the assembly should be loaded</p><p> string strPlugin=xmlreader.GetValueAsString("plugindlls",strDllname.Substring(strDllname.LastIndexOf(@"\")+1),"");</p><p> if (strPlugin != "")</p><p> {</p><p> bool bEnabled=xmlreader.GetValueAsBool("plugins",strPlugin,true);</p><p> return bEnabled;</p><p> }</p><p> else</p><p> {</p><p> return true;</p><p> }</p><p> }</p><p> }</p><p></p><p>[/code]</p><p></p><p>I've implemented the above in my local copy of the code and must say, that it works. I about halved the load time of MP with this code. This is not the most beautiful solution, but given the performance gain... what the heck.</p><p></p><p>The Configuration part still has to be done, but I don't think that would pose a problem.</p><p></p><p>Hope this comes in handy.</p><p></p><p>Regards</p><p></p><p>Ojo</p></blockquote><p></p>
[QUOTE="ojo, post: 3058, member: 10402"] Hi all, nice going, this is by far the greatest of HTPC products available.... And open source. I myself being a software developer in a Danish telecom, was eager to check out the product and have a look at some code. Doing so i stumbled upon a performance suggestion. Given the impressive number of plug-in already done, and planned for release 1.0, I would suspect that most of us won't use 100% of all the plug-ins all the time. I'd say that 50%-80% would be a common ground, and some of us might even settle with as little as 25% of the plug-ins. Checking the code and load time of the MP though suggests that 50% of the loadtime is used to fire up the plug-ins by the PlugInManager. So dwelling on that i came up with this suggestion. F.x. the [bold]LoadWindowPlugins[/bold] method doesn't know if a given plug-in is enabled or not. The problem is due to the plugin design. Only the plug-in itself knows its name. This would be ok, if it wasn't for the fact that the plugin doesn't have to be enabled, but the MediaPortal.xml (settings) doesn't know about that before instantiating and getting the plug-in name. In other words, all plug-in are loaded regardless of their usage. This wouldn't be a problem if the .NET CLR/Framework supported a way to get rid of the unwanted (only in this case) plug-ins. But since there is no Assembly.Unload() method and the loading of the assembly takes up a lot of I/O, JIT compilation, memory allocation and so forth, calling the Assembly.Load(...) should be avoided for non-enabled plug-ins at all. I've tried to do an investigation and changed some of the code to comply with that. Given the fact that the Setup/Configuration program must use all plug-ins and that is able to reference the plug-in name with the assembly name if suggest that the MediaPortal.xml could be extended like this. [code] <section name="plugins"> <entry name="My Alarm">no</entry> ... <entry name="Winamp">no</entry> </section> <section name="plugindlls"> <entry name="GUIAlarm.dll">My Alarm</entry> ... </section> [/code] Given this the PluginManager would be able to scan the directory, for every assembly, get the plug-in name and check to see if the plug-in is enabled BEFORE loading. The code below uses the above structure. [code] static public void LoadWindowPlugins() { System.IO.Directory.CreateDirectory(@"plugins"); System.IO.Directory.CreateDirectory(@"plugins\windows"); string [] strFiles=System.IO.Directory.GetFiles(@"plugins\windows", "*.dll"); foreach (string strFile in strFiles) { if (PlugInEnabled2(strFile)) { LoadWindowPlugin(strFile); } } LoadWindowPlugin("Dialogs.dll"); } ... static public bool PlugInEnabled2(string strDllname) { using (AMS.Profile.Xml xmlreader=new AMS.Profile.Xml("MediaPortal.xml")) { // from the assembly name check the reference to plugin name // if available check to see if the plugin is enabled // if the plugin name is unknown suggest the assembly should be loaded string strPlugin=xmlreader.GetValueAsString("plugindlls",strDllname.Substring(strDllname.LastIndexOf(@"\")+1),""); if (strPlugin != "") { bool bEnabled=xmlreader.GetValueAsBool("plugins",strPlugin,true); return bEnabled; } else { return true; } } } [/code] I've implemented the above in my local copy of the code and must say, that it works. I about halved the load time of MP with this code. This is not the most beautiful solution, but given the performance gain... what the heck. The Configuration part still has to be done, but I don't think that would pose a problem. Hope this comes in handy. Regards Ojo [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Performance suggestion
Contact us
RSS
Top
Bottom