Hiya, I've just upgraded, to see how well things are working, to the trunk version (svn checkout of this afternoon's version) of the server. I thought that it might be useful to try the bleeding edge version, as most of the plugins now require 6.5 or later. However, it seems incredibly slow to actually use it. I had various problems trying to convince the 'clear and rescan' to actually do what it was told, but that's a slightly different matter...
The problem is with actually using it. Performing operations with the remote are so slow as to be (IMO) unusable. On the main menu, going 'Down' from 'Now Playing' to 'Browse' takes about a second from pressing the key to actually having an effect. I thought that maybe this was some tweakable parameters, but I can't see anything. It means that scrolling through any long list is unbearable. I thought, I'd try out the new debugging feature (a recent message I saw stated that the debugging had changed quite a bit) to get out information. So I did... http://usenet.gerph.org/SlimServer/Spool-22Oct2006.txt ... contains a log of the things 'debug' output that happens when I press 'Down' to move from 'Now Playing' to 'Browse'. The timestamp of the first event which occurs is '23:36:28.0320', and the last is '23:36:29.3392'. This confirms my general feeling that button presses take about a second when using the device. It can be seen from the logs that the operation in Slim::Control::Request.pm is taking around 40cs to be processed: [23:36:28.0345] Slim::Control::Request::__parse (1915) ..Trying to match [ir] [23:36:28.4099] Slim::Control::Request::__parse (1916) do { The corresponding code in the source is... Code: -------------------- [1915] $log->debug("..Trying to match [$match]"); [1916] $log->debug(Data::Dump::dump($DBp)); -------------------- There is nothing else between these lines. The conclusion I draw from this ? Data::Dump::dump($DBp); is an incredibly slow operation which really shouldn't be used unless the debugging level required it. I don't know much about the logging functions, but if it were me I'd be tempted to make a special variation of the recording code which only operated when the level was triggered. That is, you could use something like : Code: -------------------- $log->debug("..Trying to match [$match]"); # string is always fast to generate $log->debugcallback(sub { return Data::Dump::dump($DBp); }); # The dump is AMAZINGLY slow, so we generate only if needed -------------------- I'm not entirely sure that that's even valid perl, and there's issues of scoping there for $DBp, but that operation is really costly and probably shouldn't occur unless there is some real need for the 'debug' level of logging. I know the logging has only just gone in, so there may be things like this, but spare a little thought for my poor hard-done-by 500MHz server. It's just plain cruel to make it generate all that output and then throw it away :-) Addendum: I've just commented out that line (1916) and suddenly the player is responsive again, and the world is a happy place again. Or at least, the small subset of the world that involves my pressing buttons on the remote. -- gerph ------------------------------------------------------------------------ gerph's Profile: http://forums.slimdevices.com/member.php?userid=1819 View this thread: http://forums.slimdevices.com/showthread.php?t=28960 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
