Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quick2wire GPIO is much slower than other python modules #18

Closed
RandomDude4 opened this issue Dec 22, 2012 · 6 comments
Closed

quick2wire GPIO is much slower than other python modules #18

RandomDude4 opened this issue Dec 22, 2012 · 6 comments

Comments

@RandomDude4
Copy link

It takes around 0.5 ms to change the output of one pin with the quick2wire module for me.

The "python-rpi.gpio" module found on apt-get, does the same operation in around 0.01 ms (more than 10x faster)

Although both of these are very slow, a 700 MHz processor would be able to do it in a few nanoseconds, but a slowdown of 100000 times sounds very inefficient even for python?

@npryce
Copy link
Contributor

npryce commented Dec 23, 2012

Are you running as root or as an unpriviledged user?

@RandomDude4
Copy link
Author

It does not matter if I'm root or not, however if I use the following (value change is done in a loop with timing before and after):

outpin = Pin(11, "out")
outpin.value = 1

I get around 0.4-0.5 ms per change, but with the code:

Pin(11, "out")
Pin(11).value = 1

I get even slower speeds of 2 ms per output change.

I have the quick2wire-python-api "installed" through PYTHONPATH=/xxx/quick2wire-python-api/src.

Edit:
Running in python 2.7 is faster than python 3.2 (I thought it was written for python 3, didn't even know it worked in python 2.7 untill now)
#!/usr/bin/env python --> 0.1 ms per GPIO change
#!/usr/bin/env python3 --> 0.45 ms per GPIO change

Although still 10x slower than "python-rpi.gpio" module = 0.015 ms per GPIO change in both python 3.2 and 2.7 (same script, only changed modules and syntax)

@npryce
Copy link
Contributor

npryce commented Dec 23, 2012

Sorry, I didn't make myself clear. I meant, is running as an unprivileged user important to you?

RPi.GPIO maps the GPIO device registers into the memory space of the process, which can only be done as root. This increases the attack surface you're driving GPIO from a network service exposed on the Internet. It's also a hassle during development because programming errors can crash the machine or trash your filesystem.

We're designing our API for convenience and security before raw performance. Our API goes through the user-space GPIO API, writing to files in the /sys filesystem. The kernel transition and driver layer takes a lot of time compared to direct writes to the device registers. However, our API can then be used by unprivileged processes that cannot bring down the entire machine.

It's a trade-off. If you're ok about running as root and need raw speed, say in a robotics project or if bit-banging a binary protocol, then RPi.GPIO is a better choice. If you're connecting sensors to the Internet and raw speed is not critical then our API would be a better choice (in my opinion).

We're working on closing the performance gap, safely mapping the device registers into user space without having to run as root. But that's work in progress.

@npryce
Copy link
Contributor

npryce commented Dec 23, 2012

Interesting that Python2 and Python3 have such different timings. I'll look into that. I suspect that maybe there's some unnecessary unicode to binary conversion being performed in Python3

@RandomDude4
Copy link
Author

Now I understand, in that case I am happy with the speed from your API, it's definitely more trouble having to run everything as root. I didn't know the difference between RPi.GPIO and your API before, I thought booth went through the kernel device drivers in the same manner.

Feel free to remove this issue if you want to.

@npryce
Copy link
Contributor

npryce commented Dec 24, 2012

Closed as duplicate of #6, new issue #19 raised for python 2 / python 3 performance discrepancy.

@npryce npryce closed this as completed Dec 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants