Video addon performance on Pi
#1
I am generally very pleased with the performance of my Pi running OpenELEC. Navigating the home menu, playing and navigating local video (i.e. video on local network) are very responsive and I am completely satisfied with the Pi in this important respect.

Video addons are another story. Navigating the addon menus and launching remote videos is brutally slow. In Free Cable or the PBS addons, for instance, drilling down 3 or 4 levels and launching a show takes a couple of minutes. I'd ballpark that each step ranges somewhere between 15-40 seconds. The same steps with XBMC on my mac is many times faster - each step takes maybe a second or two.

No doubt, the much faster processor on the mac makes a big difference. However, I would appreciate some feedback on the following:
- Is this extremely slow performance consistent with others' experience? I'd be OK with sluggish. Sluggish would be a big step up;
- Are there any standard optimizations that a user can use to improve performance?

I am currently using the Rbej July 3 build (XBMC 13 alpha 5) — newer builds have broken MythTV navigation.
Reply
#2
It is odd, how badly the Pi performs with video addons.

For example the difference between SportsDevil on an Atom-based x86 and a 1GHz Pi is plain to see, but I'm not really sure why - surely parsing a handful of web pages can't take that much longer on the Pi?

Without really knowing what these addons are doing during these delays, it's difficult to suggest how to improve the situation - it could be sub-optimal addon code (which works OK on the developers x86 machine, so no reason to optimise the code for improved performance on slower devices), or maybe the addons really are processing vast amounts of data before starting playback...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#3
Just guessing: slow Python interpreter on the pi.
Maybe we see some improvements with PyPy ( http://www.raspberrypi.org/archives/4363 ) some day?
Reply
#4
(2013-08-12, 20:58)fraz0815 Wrote: Just guessing: slow Python interpreter on the pi.
Maybe we see some improvements with PyPy ( http://www.raspberrypi.org/archives/4363 ) some day?

That will be nowhere near soon.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#5
(2013-08-12, 20:58)fraz0815 Wrote: Just guessing: slow Python interpreter on the pi.
Maybe we see some improvements with PyPy ( http://www.raspberrypi.org/archives/4363 ) some day?
Would this enhancement be within the scope of XBMC, or would it be more of an OS thing (like OpenELEC)?
Reply
#6
(2013-08-12, 20:58)fraz0815 Wrote: Just guessing: slow Python interpreter on the pi.
Maybe we see some improvements with PyPy ( http://www.raspberrypi.org/archives/4363 ) some day?

Right now there are no plans for PyPy, and having just installed the latest ARM hard float nightly with jit on a 1GHz Pi running Raspbian, and observed a Python application taking over 10 times longer in PyPy[1] it's got a long way to go...

1. Running "texturecache.py config" which reads a config script and ouputs the values.
With Python 2.7.3:
Code:
time python2.7 ./texturecache.py config
...
real    0m1.211s
user    0m1.020s
sys     0m0.090s
With pypy-c-jit-66157-efbddbfc2569-linux-armhf-raspbian:
Code:
time pypy-c-jit-66157-efbddbfc2569-linux-armhf-raspbian/bin/pypy texturecache.py config
...
real    0m13.231s
user    0m12.370s
sys     0m0.120s

(2013-08-15, 01:27)allan87 Wrote: Would this enhancement be within the scope of XBMC, or would it be more of an OS thing (like OpenELEC)?

I'd imagine the addition of PyPy would need to be a "core" technology for XBMC, rather than something added by individual distributions with varying degrees of success and subsequent support headaches when some addon doesn't play well with PyPy ("Why doesn't addon X work with distribution Y? XBMC is so cr@p", etc.).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#7
(2013-08-15, 03:44)MilhouseVH Wrote: Right now there are no plans for PyPy, and having just installed the latest ARM hard float nightly with jit on a 1GHz Pi running Raspbian, and observed a Python application taking over 10 times longer in PyPy[1] it's got a long way to go...

Interesting. You should report that to them. Might be something they can fix.
(pypy is obviously not ready for xbmc, but it has potential to be useful for the future)
Reply
#8
(2013-08-15, 12:33)popcornmix Wrote: Interesting. You should report that to them. Might be something they can fix.
(pypy is obviously not ready for xbmc, but it has potential to be useful for the future)

Yeah, it was a little unexpected to say the least. I also tried PyPy on an x86 (Ubuntu) box - same test - and again the performance was quite disappointing. I'll try and spend some time later today or tomorrow narrowing down the cause of the delay, the script is importing quite a bit maybe that's where PyPy trips up, but in terms of actual processing there's really not very much going on that could account for it.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#9
Thanks for investigating and sharing your test results.
Reply
#10
Update on PyPy performance: loading of imports is accounting for virtually all of the runtime cost. However, sqlite is the biggest culprit.

Using the following as a test:
Code:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys
import sqlite3 as lite
import os, platform, json, re, datetime, time
import socket, base64, hashlib
import threading, random
import errno, codecs

def main(argv):
  sys.exit(0)

main(sys.argv[1:])

then commenting out various imports (apart from sys) shows that PyPy, on average - but without sqlite3 - takes between 2 and 4 times longer to run than regular Python (v2.7.3 under Raspbian on a 1GHz Raspberry Pi). This is testing with pypy-c-jit-66157-efbddbfc2569-linux-armhf-raspbian (nightly as of 15 August).

With the sqlite3 module included, however, PyPy is up to 50 times slower. Eek

Importing just sys:

Code:
PyPy...

real    0m0.491s
user    0m0.440s
sys     0m0.040s

Python...

real    0m0.136s
user    0m0.090s
sys     0m0.040s

PyPy      :  0.523 s
Python    :  0.173 s
Relative x:  3.0

Importing sys + sqlite3:
Code:
PyPy...

real    0m9.565s
user    0m9.040s
sys     0m0.140s

Python...

real    0m0.160s
user    0m0.140s
sys     0m0.010s

PyPy      :  9.595 s
Python    :  0.194 s
Relative x: 49.5

The situation improves slightly, when importing all of the modules (including sqlite3) as PyPy is only 24 times slower:
Code:
PyPy...

real    0m10.102s
user    0m9.540s
sys     0m0.160s

Python...

real    0m0.391s
user    0m0.360s
sys     0m0.030s

PyPy      : 10.136 s
Python    :  0.423 s
Relative x: 24.0

sqlite3 is a supported module according to the PyPy compatability page.

In its simplest form, the following demonstrates why PyPy is currently a total non-runner (at least on R-Pi, for local database work):
Code:
pi@raspberrypi ~/pypy $ time pypy-nightly/bin/pypy -c "import sqlite3"

real    0m9.574s
user    0m9.020s
sys     0m0.160s

Hopefully the PyPy developers are aware of this problem.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#11
I'm also able to reproduce a similar delay on x86 (Ubuntu 13.04, AMD FX-8350 @ 4GHz, PyPy x86_64 jit nightly dated 16 August):

Code:
$ time pypy-nightly/bin/pypy -c "import sqlite3"

real    0m0.372s
user    0m0.328s
sys     0m0.048s

$ time python -c "import sqlite3"

real    0m0.011s
user    0m0.000s
sys     0m0.008s

PyPy is about 33x slower than Python 2.7.4 when loading the sqlite3 module.

When loading all modules other than sqlite3 (see test script in post #10), PyPy is about 2x slower than Python.

Obviously, given the much faster performance of the x86 hardware, these delays are barely noticeable. Not so on the Pi...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#12
MilhouseVH,

PyPy needs the jit to warmup otherwise it will have poor performance. So it works much better on long running processes rather than very small work loads. If running code on CPython takes less than a sec than it rather pointless to compare it's running time with PyPy's time.

I'm not familiar with this project and haven't looked at the code so this next comment may not be applicable. Make sure you are not running running your Python code like cgi scripts. That is don't run a Python script every time you have to respond to a command but rather rather have a long running process that handles the commands. Starting up CPython and PyPy is a rather expensive operation and so are imports to some extent. Having a long running process will avoid repeat these operations over and over again.
Reply
#13
@camara: 10 seconds (on a Pi) to import one module is clearly not right, jit warmed up or otherwise. There's something about the sqlite3 module that causes PyPy to stumble badly.

Even if PyPy is most beneficial on long running processes (and that sounds entirely plausible) it's got an immediate deficit to make up when it takes 10 seconds longer than standard Python just to get itself off the ground.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#14
sqlite3 on PyPy uses the cffi module which parse c files during the import which is the reason why it is slow. It's a known issue and a future version of cffi module will likely change this so that this parsing can be skipped during the import and instead done once during installation time.

For now just use a long running process and you just take the hit on startup. This will provide you will have commands that will execute with much lower latency.
Reply
#15
That's good to know, thanks camara.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply

Logout Mark Read Team Forum Stats Members Help
Video addon performance on Pi0