[Esbjornsson]

An addon that is incredibly slow on RPi is TedTalk.

[isilver18]

It's a shame we haven't overcome this problem yet.

[evangelion]

Really? I use TedTalks all the time, takes maybe five seconds to launch once clicked, browsing seems to be fairly fluid and quick also. Bit surprised you guys are struggling.

Edit: Sorry, didn't notice there were two other pages to this thread, thought it was a random comment!

Still stands though, I have no issues with the load and browse times.

[popcornmix]

It's a shame we haven't overcome this problem yet.

Can you describe an add-on with a problem, and time how many seconds it does to do various operations (e.g. navigating though menu levels and starting video playback).

We can then determine if your setup is slower than others (in which case some change of settings may help you),
or whether something can be done in xbmc, or the add-on to make it faster.

[evangelion]

Just timed "George Takei: Why I love a country that betrayed me" (TedTalks) 5 seconds dead from click to play.

[allan87]

I have not timed USTV VoD, and the delay would depend on the content of the menu you are drilling into, but it is easily over 30 seconds and often more for each click. Sometimes much more.

Since many clicks are required before you find something, it is unusably slow on the Pi.

---

Just timed "George Takei: Why I love a country that betrayed me" (TedTalks) 5 seconds dead from click to play.

I don't believe the delay problem, generally, is delay to start playing when you are already at the content you want. The problem is navigating there through a menu structure that is parsed very slowly.

This is a general comment and may not be relevant to the TEDtalks addon, which I have never used.

[w84no1]

XBMB3C runs fine on a PC, but is slow on a Pi. It has improved since the first version, but not quite there for the Pi.

[LehighBri]

I also have an rpi running OpenELEC 4.0.7 (Gotham 13.1) and I think the main issue with speed is the of python parsing and execution (which addons are written in). From the time I click Play to when playback of video starts, it is usually only a couple seconds which is totally fine.

But yes, menu navigation in general is definitely less than ideal (bearable, but barely). I do know the performance of the rpi in general was improved tremendously from Frodo to Gotham, so I wonder if things have simply "plateaued", or if there's any additional room for improvement to continually try to speed up the python addons and related processing on the rpi.

[da-anda]

if an addon is fast really depends on how it's coded and what it's doing in the background. Addons that are using official APIs (like JSON) should usually be fast, but addons that need to extract links from websites using regular expressions are very CPU intensive and thus slow on the PI

[popcornmix]

if an addon is fast really depends on how it's coded and what it's doing in the background. Addons that are using official APIs (like JSON) should usually be fast, but addons that need to extract links from websites using regular expressions are very CPU intensive and thus slow on the PI

The slow regexes can often be improved in the add-on. I believe sportsdevil used to take minutes to extract links due to a complicated regex with multiple wildcards. (It was pretty slow on faster platforms too).
It was adjusted to split into two simpler regexes and ran several times faster.

I think Milhouse identified some issues with iplayer where the regexes were being compiled on every use (without changing), rather just at startup, which again helped.

[DBMandrake]

To some extent XBMC on Pi is just revealing how inefficiently coded and completely lacking in optimisation some code is these days - when you're testing on a quad core 2.4Ghz desktop class CPU (as many addon authors probably are) if you write inefficient code you might not even be aware of it because its "fast enough" for good user interaction on a big beefy processor, even if its orders of magnitude slower than it could be.

Some of the inefficiencies millhouse found were pretty horrifying - static patterns being recompiled thousands of times just to navigate one menu step for example. The mind boggles. While I'm sure there is still some room to optimise the python environment itself on the Pi it does seem like the biggest gains will only come from the individual addon authors optimising their code properly, perhaps with a bit of help from some best practices guidance.

So there probably isn't a magic bullet that would allow addons to run much faster on a future version of XBMC on Pi - its up to the addon developers to actually optimise their code, rather than just code until it functions.

[LehighBri]

To some extent XBMC on Pi is just revealing how inefficiently coded and completely lacking in optimisation some code is these days - when you're testing on a quad core 2.4Ghz desktop class CPU (as many addon authors probably are) if you write inefficient code you might not even be aware of it because its "fast enough" for good user interaction on a big beefy processor, even if its orders of magnitude slower than it could be.

Some of the inefficiencies millhouse found were pretty horrifying - static patterns being recompiled thousands of times just to navigate one menu step for example. The mind boggles. While I'm sure there is still some room to optimise the python environment itself on the Pi it does seem like the biggest gains will only come from the individual addon authors optimising their code properly, perhaps with a bit of help from some best practices guidance.

So there probably isn't a magic bullet that would allow addons to run much faster on a future version of XBMC on Pi - its up to the addon developers to actually optimise their code, rather than just code until it functions.

Agree 100%. I'm assuming in some cases addon devs may not know the best practices for certain things and thus code things inefficiently without knowing it.

One addon which I'd love to hear/see if it's optimized is XBMB3C (Mediabrowser addon). I use it all the time (as do many others), but it still takes 10-15 seconds to navigate through the menu and media on my pi (using Gotham 13.1). I know they recently switched over from using simplejson to json which definitely helps, but I'm wondering if there's anything further that can be done.

If anyone is interested to take a look and see, it'd be great to hear if there's any additional improvements that anyone might spot upon a quick glance at the code: https://github.com/MediaBrowser/MediaBrowser.XBMC

[popcornmix]

Agree 100%. I'm assuming in some cases addon devs may not know the best practices for certain things and thus code things inefficiently without knowing it.

One addon which I'd love to hear/see if it's optimized is XBMB3C (Mediabrowser addon). I use it all the time (as do many others), but it still takes 10-15 seconds to navigate through the menu and media on my pi (using Gotham 13.1). I know they recently switched over from using simplejson to json which definitely helps, but I'm wondering if there's anything further that can be done.

If anyone is interested to take a look and see, it'd be great to hear if there's any additional improvements that anyone might spot upon a quick glance at the code: https://github.com/MediaBrowser/MediaBrowser.XBMC

It really needs profiling. I'm not very familar with python/addons to know the best scheme. The simple scheme is to add code to time various calls and try to determine where the time is spent.
There may be python tools that can do this automatically, but I'm not familiar with them.

O a quick look this jumped out:

Code:

def remove_html_tags( data ):
    p = re.compile(r'<.*?>')
    return p.sub('', data)

Now if this is called frequently, then just doing the re.compile once during startup may help. If it's only called a few times, then it may not matter.

[LehighBri]

Great, thanks for the quick look at things. Yes the addon dev has added a performance profiling feature which creates some enhanced logs, so I'll probably do that and see what happens.

[LehighBri]

@popcornmix - I see the MB3 devs might be considering more optimal ways to get information from a URL (aka the mb3 server).

Any thoughts or guidance on the following potential optimization regarding keeping http connection open to speed things up?

http://stackoverflow.com/questions/20092...e-requests