matplotlib-devel Mailing List for matplotlib

On Tue, Jul 30, 2013 at 2:28 PM, Michael Droettboom <md...@st...> wrote:
> As promised in last week's Google Hangout to the IPython developers
> meeting -- I have some concrete timings and numbers on the matplotlib
> WebAgg backend in a couple of different scenarios.
>
> First, let me apologize -- the way I was timing binary websockets vs.
> text websockets previously was wrong. The actual impact of it is much
> smaller than I had originally estimated -- so the discussion about
> whether to include binary websockets in IPython may have been all for
> naught.
>
Part of our message spec includes binary blobs trailing after the JSONable
message dicts.
Currently this is used by `data_pub` and `apply` messages, but it could
theoretically be extended to display data for streaming output, such as
video or audio. Right now, we have no way of propagating that part of the
message spec up to notebook frontends, because we do not yet have any
binary messages that the notebook frontend can understand. In these cases,
a switch to binary websocket may still make sense, even without a
performance argument.
>
> For benchmarking, I used two different plots. One is the classic
> "simple_plot.py" sine wave, which tests sort of the "easy case" where
> very little of the image is updated in each frame, and the other was
> "animation/dynamic_image.py" in which most of the plot is updated in
> each frame.
>
> I tested both scenarios with client and server on my local machine, and
> through an ssh tunnel that goes over wifi, the public university
> network, to my home's 15/5 MBps cable connection 28 miles away and back.
>
> For (A), the average frame weighs in at around 20kb. For (B), it's
> around 90kb. For base64, multiply by those numbers by 4 / 3.
>
> On my local machine, I can push through about 18 fps, so a bandwidth of
> 2.8MBps (were it sustained, which it rarely is). On the tunnel, I
> fluctuate between 7 and 10 fps, which is quite usable, and quite near
> the practical upper limit on the bandwidth of that connection.
>
> However, the problematic thing for the remote connection is the
> latency. Locally, I average a fairly steady 250ms to roundtrip from a
> mouse event to an updated frame. Remotely, it fluctuates randomly
> between 400ms (still usable) and 3000ms. Some more careful dynamic
> scaling of events can probably make that easier to use, perhaps. I know
> games often use UDP and handle robustness to packet loss in a different
> way as a way to remove some of the latency of TCP. I have no idea if
> such a thing would be possible over a web socket, of course.
>
> I could not measure any statistically significant change in framerate or
> latency between a binary websocket and a non-binary one. However, there
> is a 10% increase in CPU time on both the python side and the browser.
> It so happens that I wasn't saturating my CPU, so it had no net impact.
> Likewise, I am not saturating my bandwidth, so the additional size
> doesn't matter in this case. But I suspect if either one of those
> resources is starved, the additional 10% cpu time and 25% bandwidth
> increase may matter.
>
Thanks for these numbers - I suspect the potential penalty for an extra hop
between the kernel and the notebook will not be significant in any case
where the kernel is local to the server and the client is remote.
-MinRK
>
> Mike
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

I am glad that the numpy and scipy projects are still creating binary installers for python.org python, but it is a serious problem for users of the matplotlib binary installers that they are so difficult to find.
If a user googles for "numpy download" then the user finds this page
<http://www.numpy.org>
and the link Getting Numpy points to this page
<http://www.scipy.org/install.html>
which does not the binary installers at all.
I agree that most users should probably use Anaconda or its ilk, but I think it would be good to mention the Mac and Windows python.org binary installers quite prominently after that.
-- Russell
On Aug 7, 2013, at 1:00 PM, Thomas Kluyver <th...@kl...> wrote:
> On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
> P.S. the Mac binary installer for numpy used to be easy to find. I was
> quite dismayed to find how buried it had become when I went looking for
> it a week or two ago.
> 
> Is this down to the redesign of the SciPy site. If so, blame me ;-). I felt, and others seemed to agree, that setting up individual packages separately wasn't a route that we wanted to promote to newcomers, so the new site emphasises all-in-one installers that get you the whole Scipy Stack (numpy, scipy, matplotlib, etc.) in one go.
> 
> Thomas

On Wed, Aug 7, 2013 at 4:00 PM, Thomas Kluyver <th...@kl...> wrote:
> On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
>
>> P.S. the Mac binary installer for numpy used to be easy to find. I was
>> quite dismayed to find how buried it had become when I went looking for
>> it a week or two ago.
>>
>
> Is this down to the redesign of the SciPy site. If so, blame me ;-). I
> felt, and others seemed to agree, that setting up individual packages
> separately wasn't a route that we wanted to promote to newcomers, so the
> new site emphasises all-in-one installers that get you the whole Scipy
> Stack (numpy, scipy, matplotlib, etc.) in one go.
>
> Thomas
>
>
All-in-one installers are fine, but I don't think it should exclude access
to the individual installers as well (for the intermediate users, for
example).
Ben Root

On 7 August 2013 12:54, Russell E. Owen <ro...@uw...> wrote:
> P.S. the Mac binary installer for numpy used to be easy to find. I was
> quite dismayed to find how buried it had become when I went looking for
> it a week or two ago.
>
Is this down to the redesign of the SciPy site. If so, blame me ;-). I
felt, and others seemed to agree, that setting up individual packages
separately wasn't a route that we wanted to promote to newcomers, so the
new site emphasises all-in-one installers that get you the whole Scipy
Stack (numpy, scipy, matplotlib, etc.) in one go.
Thomas

In article <51F...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> Ludwig, this is one of the most entertaining e-mails I've read in a 
> while, and I think your arguments make a lot of sense.
> 
> Given infinite developer resources, do you think there's any logic to 
> providing *both* system Python and python.org based binaries? How much 
> additional work would that be?
> 
> I think the big problems to solve now is
> 
> (a) get to the bottom of why the new installer is breaking existing 
> installations of dateutil and pytz. Russell: even though they are not 
> currently working, could you provide what you have so that others can 
> have a look?
I put the installer here (and announced it earlier -- I thought in this 
thread):
<http://www.astro.washington.edu/users/rowen/python/>
I do not consider it safe because:
- It may trash existing installations of dateutil and pytz (especially 
those installed by the matplotlib 1.2.1 binary installer)
- It does not include pytz, dateutil and six (unlike the 1.2.1 binary 
installer), so it's a real pain to use
- It is missing its unit tests and so is poorly tested
- It also appears that pylab is broken (something I only recently 
discovered)
Unless somebody figures out how to include the dependencies, I think a 
Mac binary installer is a nonstarter.
-- Russell
P.S. the Mac binary installer for numpy used to be easy to find. I was 
quite dismayed to find how buried it had become when I went looking for 
it a week or two ago.