[Milhouse]

@MilhouseVH, @miappa, @rbej,
There are some new PRs by Ben Avison looking at reducing the idle cpu load in xbmc (specifically on pi).
Together they should reduce CPU load by about 7.5% on a non-overclocked pi.
https://github.com/xbmc/xbmc/pull/3674
https://github.com/xbmc/xbmc/pull/3676
https://github.com/xbmc/xbmc/pull/3677

This is most obvious when on a static screen, but it should always have some benefit (e.g. when playing video).

I've pulled the commits into newlock3 and they work for me. I'd be interested if you can see any benefit, and if there are any regressions.

Definitely worth wider testing! With the above patches I'm seeing about 5% CPU load reduction in stock Confluence while idle on a 1GHz Pi (500Mhz core, 600Mhz SD-RAM) - idle CPU now hovers around 18% (23-24% previously).

Here's the new OE Gotham build on (Obsolete build - see later post for newer build).

Build details:

• Tip of xbmc master (93077e6)
  
• Tip of OpenELEC master (a1cd9cf)
  
• Includes all newclock3 patches other than 3b5ad1e (cheaper GUI spinner)
  
• Includes PR:3671 to ensure consistent webserver/GUI artwork caching
  
• Excludes fernetmenta OpenELEC audio settings patch
  

You'll note from the list of newclock3 commits that there are two recent commits (55d3faa, 3af0df7) aimed at improving DVD subtitle synchronisation, so anyone having problems with subtitle synchronisation might want to give this build a go.

---

This is good news indeed! I started looking at the source code yesterday, as I want to implement some speed ups on the EPG, especially when showing multiple days.

Looking at it quickly, it appears the way in which the EPG is generated is pretty inefficient (could be wrong about this). Also, I cannot work out how the cache works here, but again, not well used. My observations are that it's not the data fetching that's slow, but the way the Pi is trying to build the layout. On non-pi devices, there doesn't appear to be much of an issue.

I don't know if the EPG uses xml in any way, but there was some discussion on the OpenELEC issues list about using a more efficient XML parser library. Following one of the links in the discussion, it seems there are very significant performance differences between the different libraries (as much as 5 to 1), which makes me wonder if poor addon performance on Raspberry Pis is in many ways attributable to inefficient XML parsing.