<?sphp $this->text('pagetitle') ?>
 
Home of the Squeezebox™ & Transporter® network music players.

Logitech Media Server opimisation

From SqueezeboxWiki

Revision as of 01:24, 11 November 2011 by Soulkeeper (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Candiates for Optimisation

The following are candiates for optimisation based on profiling runs on the 7.2 server.

1) Use Class::C3::XS

Class::DBIx makes extensive use of Class::C3 with next::method high in the profile list

  • done - 7.2.1

Class::C3::XS profiles approx 4 times faster and should be considered for shipping with the server.

  • done - 7.2.1

2) Slim::Control::Request

Slim::Control::Request appears high in the profile list for most operations and is a strong candidate for optimsation, suggestions include:

  • use of more efficient accessors and bypassing accessors when accessing object data from within the module
  • remove some of the defensive code such as calling blessed to check for an object for code which is only called from within the module
  • optimise the notify mechanism to allow subscribers to register a filter rather than always calling their callbacks
  • introduce alternative isNotCommand/isCommand calls using regexps rather than arrays of verbs as this will be faster - this will require api change for caller (do we really need the isNotCommand calls for all requests/commands when created from internal execute statements?)
  • optimise __parse & __validate as they impact the performance of $request->new
  • all improved in - 7.2.1

3) Slim::Hardware::IR

Scrolling up and down long lists with the remote incurs significant processing in Slim::Hardware::IR.

Consider caching the function for the last ir button as in many cases we deal with a stream of repeated ir codes - this may speed this up.

Both ir and button commands go through execute and so incure significant overhead creating and processing the request object. Consider whether we could process these directly within Slim::Hardware::IR and use notifyFromArray to inform others? (this depends on whether plugins need to be able to replace default ir and button processing?)

4) Slim::Utils::Timers

Slim::Utils::Timers::killTimers is relative expensive. We can probably make better use of the the timer id to allow a caller to remember its timer and ask for it to be removed without walking the full timer list

5) Display code

Consider optimising Slim::Display::Lib::Fronts:string for the common case (excluding TTF etc) as it takes significant time to execute. Note that Slim::Disiplay::Graphics::render attempts to cache results of string to avoid calling it. However this is undermined by calls to measureText.

Optimise measureText to cache the result and also minimise repeat calls to measureText to trim strings for the display as they are expensive.