John Hunter wrote:
> On Jan 15, 2008 7:46 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> Ah -- just thought of something else.
>>
>> If I adjust simple_plot_fps.py to have 100,000 data points rather than
>> 1,000 I see something that starts to match with what you're seeing:
>>
>> GtkAgg:
>> wallclock: 4.23297405243
>> user: 3.33
>> fps: 23.6240522057
>>
>> Gtk:
>> wallclock: 15.0203828812
>> user: 14.92
>> fps: 6.65761990165
>>
>> TkAgg:
>> wallclock: 4.8252530098
>> user: 4.67
>> fps: 20.7243018754
>>
>> You can see that the Gtk time is starting to explode. If I go to
>> 1,000,000 points, Gtk runs out of memory before the first plot, whereas
>> the other two continue to chug along at a reasonable pace.
>>
>> From looking at the code, I suspect the crucial difference is that the
>> Gdk backend uses the Python sequence API (rather slow) to access the
>> data as it gets rendered, whereas GtkAgg uses the numpy array interface
>> which is essentially raw access to a C array.
>
> This is not likely to be the culprit -- for drawing markers, the old
> matplotlib API made a separate call to draw_polygon for every marker,
> with a new gc each time. Many moons ago, we implemented draw_markers
> as a renderer method to avoid this problem. For hundreds of thousands
> of markers, we saw performance benefits of 25x to 100x. The backends
> which implement draw_markers (Agg and PS) get the benefits, but the
> other backends which did not are still slow. Basically it is a problem
> with a lot of redundant function call overhead. The backend_bases
> renderer method _draw_markers discusses this a little bit (it is
> underscore hidden).
Markers are not the issue here. These benchmarks were done with lines.
There are markers for the ticks, of course, but the number of those
are fixed. I agree it's function call overhead, but I believe it's in
the overhead of PySequence_GetItem vs. array[index]. In both cases, the
line is still getting drawn with a single Python -> C function call.
> My guess is this difference will not be so pronounced on the trunk.
Actually, I'm getting surprising results there. Numbers are in fps.
Gtk GtkAgg
0.91.2, 1000 points 50 26
0.91.2, 10000 points 6 23
trunk, 1000 points 38 31
trunk, 10000 points 3 9
So, yes, the ratio between Gtk and GtkAgg on the trunk is not as
pronounced. I'm a little disappointed by the timings on the trunk --
while one could say that Agg is a little better on the trunk with 1000
points, it doesn't scale nearly as well. That's certainly something to
look into -- and I don't have any thoughts offhand. I would expect the
trunk to do better since it doesn't perform a memory copy on the data
with each call to draw_line/draw_path.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
