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.
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.
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
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>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;
}
}
}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
Netherlands