<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/"/>

<title>Jeff Epler's blog</title>
<modified>2012-03-06T01:35:28Z</modified>
<tagline>Photos, electronics, cnc, and more</tagline>
<author><name>Jeff Epler</name><email>jepler@unpythonic.net</email></author>
<entry>
<title>Every once in a while, ssh is too slow</title>
<issued>2012-03-06T01:35:28Z</issued>
<modified>2012-03-06T01:35:28Z</modified>
<id>https://gamma.unpythonic.net/01330997728</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01330997728"/>
<content type="text/html" mode="escaped">

I'm using my OLPC XO-1 as a music server which allows anyone in the household
the ability to play, stop, pause, adjust volume, and so on.  This was first
done by 'ssh olpc ...', but there's a substantial delay between issuing
the action and its effect.  So I wrote a simple web service that does the same
thing.  It turns out that most of the time is ssh overhead that's not present
in a http connection.

&lt;p&gt;&lt;pre&gt;
$ time ssh olpc /home/olpc/bin/cmus-playpause
real  0m0.522s
$ time wget -O /dev/null http://olpc:8000/playpause
real  0m0.066s
&lt;/pre&gt;

&lt;p&gt;It's nothing like the &lt;a href=&quot;https://gamma.unpythonic.net/01330399156&quot;&gt;384x speedup I got&lt;/a&gt;
the last time I was complaining about the olpc's performance, but it's still
nothing to sneeze at.
</content>
</entry>
<entry>
<title>Every once in a while, Python is too slow</title>
<issued>2012-02-28T03:19:16Z</issued>
<modified>2012-02-28T03:19:16Z</modified>
<id>https://gamma.unpythonic.net/01330399156</id>
<link rel="alternate" type="text/html" href="https://gamma.unpythonic.net/01330399156"/>
<content type="text/html" mode="escaped">

I recently acquired a USB-connected relay that controls a standard power outlet,
called the &amp;quot;USB NET POWER 8800&amp;quot;.  I'd ordered this with the knowledge that
there was a Python implementation of the control program that was said to run
on Linux.

&lt;p&gt;It does work, but I was stunned at how long it took to switch the outlet on
or off: a couple of seconds!  I should disclaim that it's running on a rather
underpowered machine (the OLPC XO-1 with a Geode x86 CPU @ 430MHz), but this
was way too long to be acceptable:
&lt;pre&gt;
$ time py-usbpower query
Power: on

real    0m2.690s
user    0m1.484s
sys     0m0.096s
&lt;/pre&gt;
With some detective work, I discovered that ctypes is doing things like running
the compiler, objdump(!) and ldconfig(!), several times (!!), at each
invocation of the program. (this is python2.5, but it looks like Python 2.7's
ctypes still does essentially the same thing, unfortunately)

&lt;p&gt;I set about to code this in C.  For my reward, I got a very fast-executing
program:
&lt;pre&gt;
$ time c-usbpower status
ON

real    0m0.007s
user    0m0.000s
sys     0m0.000s
&lt;/pre&gt;

&lt;p&gt;That's something like a 384x speedup.  Lesson?  ctypes has some very
substantial startup costs for loading a library.  It may be enough to make it
unsuitable for a short-lived program.

&lt;p&gt;In case it's useful to you, I enclose a copy of my usbpower program.  It's
under the terms of the GNU GPLv2.

&lt;p&gt;&lt;p&gt;&lt;b&gt;Files currently attached to this page:&lt;/b&gt;
&lt;table cellpadding=5 style=&quot;width:auto!important; clear:none!important&quot;&gt;&lt;col&gt;&lt;col style=&quot;text-align: right&quot;&gt;&lt;tr bgcolor=#eeeeee&gt;&lt;td&gt;&lt;a href=&quot;https://media.unpythonic.net/emergent-files/01330399156/usbpower.c&quot;&gt;usbpower.c&lt;/a&gt;&lt;/td&gt;&lt;td&gt;3.4kB&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;&lt;p&gt;
</content>
</entry>
</feed>
