[WiP] Log performance improvements (1 Viewer)

Neos

Portal Member
February 14, 2008
18
15
Home Country
Netherlands Netherlands
This patch's main intent is to improve the performance of the one method that is, obviously, called the most throughout any application. It changes the ILog interface removing the params object[] args from each of the logging methods: Info, Error, Warn and Debug. Internally when not specifying any arguments the compiler generates an empty object array for you. The framework's developers optimized calls to such methods by overloading them with a default of 3 extra arguments (see Console.WriteLine or String.Format). For an log-line that requires less than 3 arguments this is about 3-4 IL instructions less. Adding extra overloads is simple and truly worth the performance gain, especially in projects that make extensive use such of the params keyword.

When the callee does require formatting of his log a new set of overloads has been added to the static Log classes in MediaPortal.ServiceImplementations and MediaPortal.GUI.Library. These overloads call string.Format passing the formatted string to the actual instance of the ILog interface. For each log method 3 overloads exists fully exploiting the the string.Format optimizations in the Framework.

In addition I have removed several direct calls to the GlobalServiceProvider class in favor of the static log classes. The USBUIRT Plugin kept a local reference to the the central ILog interface, this has also been replaced with a call to the static log class.

Edit: In all my I forgot one crucial thing, still in essence this patch should improve performance be it not that the formatting isn't done when for messages not written to the log. My patch does (sadly enough), at this point in time, always format text even if it is not logged. Rather careless of me to to this before submitting my patch. Tomorrow I will provided a better version that DOES do what it should do.
 

Attachments

  • log_performance.patch
    33.3 KB

SilentException

Retired Team Member
  • Premium Supporter
  • October 27, 2008
    2,617
    1,130
    Rijeka, Croatia
    Home Country
    Croatia Croatia
    Yup, thanks so much Neos. But the patches will have to wait until 1.2 is released. We're in the future freeze.

    Bug fixes are still allowed to go in, so if you try to separate bug fixes from optimizations/features, I'll try to take a look ASAP.
     

    SilentException

    Retired Team Member
  • Premium Supporter
  • October 27, 2008
    2,617
    1,130
    Rijeka, Croatia
    Home Country
    Croatia Croatia
    Not really, if anything it would slow our already (too) long release cycle even more. At this point we need to concentrate on finding and fixing any bugs and not on new features. Sadly, closing trunk (feature freeze) is only option to somehow force developers to do that.
     

    Neos

    Portal Member
    February 14, 2008
    18
    15
    Home Country
    Netherlands Netherlands
    Yup, thanks so much Neos. But the patches will have to wait until 1.2 is released. We're in the future freeze.

    Bug fixes are still allowed to go in, so if you try to separate bug fixes from optimizations/features, I'll try to take a look ASAP.

    No problems, I must say this is indeed more of a performance feature then bug fix. I'll seperate it into a bug fix and repost the improved performance feature for the log later.

    Edit: Added a patch that fixes several classes that accessed the log through the GlobalServiceProvider class instead of the static Log class.
     

    Attachments

    • ilog_ref_patch.patch
      5.2 KB

    Users who are viewing this thread

    Top Bottom