About a week ago I sent a message to the users mailing list with tick mark
performance problems. I now have a proof of concept patch which (mis-)uses the
projection keyword in add_subplot to use a custom Axes class. Import one
python file, use "projection='fastticks'" -> boring scatter plots render about
2x as fast and plots with lots of minor ticks render 6x faster.
The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is in
fastaxes.py which uses a single Line2D for all tick marks of a given flavor
rather than a Line2D for every single tick mark.
There are two reasons this isn't a total win:
1) it's not done yet in all tick/grid configurations.
2) it loses flexibility in tick labeling
The lost flexibility may matter a great deal to other people. In my use-case,
the labeling flexibility simply seems misguided and the performance is much
much preferred.
Comments welcome about how this could move forward toward being included in
MPL.
Joel
This is very interesting. I have also noticed that ticking has been a bottleneck in rendering, but always suspected the computation of the ticks rather than the actual rendering of the marks. Perhaps this might spur some renewed interest in identifying the specific reason for the bottleneck and solving that issue now that we know that there are significant performance gain potential here?
Looking forward to reviewing this at some point in the next few weeks.
Cheers!
Ben Root
···
On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <joel@…1193…> wrote:
About a week ago I sent a message to the users mailing list with tick mark
performance problems. I now have a proof of concept patch which (mis-)uses the
projection keyword in add_subplot to use a custom Axes class. Import one
python file, use “projection=‘fastticks’” → boring scatter plots render about
2x as fast and plots with lots of minor ticks render 6x faster.
The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is in
fastaxes.py which uses a single Line2D for all tick marks of a given flavor
rather than a Line2D for every single tick mark.
There are two reasons this isn’t a total win:
-
it’s not done yet in all tick/grid configurations.
-
it loses flexibility in tick labeling
The lost flexibility may matter a great deal to other people. In my use-case,
the labeling flexibility simply seems misguided and the performance is much
much preferred.
Comments welcome about how this could move forward toward being included in
MPL.
Joel
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
This is very interesting. I have also noticed that ticking has been a
bottleneck in rendering, but always suspected the computation of the ticks
rather than the actual rendering of the marks. Perhaps this might spur some
renewed interest in identifying the specific reason for the bottleneck and
solving that issue now that we know that there are significant performance
gain potential here?
I'm thinking about "specific reasons":
1) Path.__init__ does mysterious stuff (at least, mysterious to me) and seems
designed to handle many different inputs in various stages of readiness for
something. It is also called many times in the course of getting a graph on
screen and it isn't very fast. I think the checking and rechecking vertices is
needlessly expensive in particular around TransformedPath. This is deep stuff
and I'm too novice.
1a) Line2D.recache is a big hunk in the profiler, but that's partly due to #1.
2) The loops in axis.py over major_ticks and minor_ticks are repeated in time
sensitive areas and apply the same things to many sub-objects. This is the
issue that my current ideas are addressing.
3) If one addresses 1&2, the next largest elephant appears to be text
rendering.
While fixing #1 is a really good idea, it's hard work and the multitude of
explicit tick objects of #2 will always have a great deal of python call
overhead.
Fixing #3 has little low-hanging fruit. I've seen
Faster Text drawing needed · Issue #347 · matplotlib/matplotlib · GitHub and a 20% gain would be
a noticeable improvement on the graphs I'm working on (but only after #2 is
addressed). Of course, I'm not sure of what total quantity mdboom's 20%
referred to.
Joel
PS: all of these thoughts are brought to you by snakeviz ... nice profile
visualizer
···
On Thu, Jun 26, 2014 at 02:36:28PM -0400, Benjamin Root wrote:
Looking forward to reviewing this at some point in the next few weeks.
Cheers!
Ben Root
On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <joel@...1193...> > wrote:
> About a week ago I sent a message to the users mailing list with tick mark
> performance problems. I now have a proof of concept patch which
> (mis-)uses the
> projection keyword in add_subplot to use a custom Axes class. Import one
> python file, use "projection='fastticks'" -> boring scatter plots render
> about
> 2x as fast and plots with lots of minor ticks render 6x faster.
>
> The code is at GitHub - jbmohler/mplfastaxes: prototype for optimized MPL tick marks ; the core idea is
> in
> fastaxes.py which uses a single Line2D for all tick marks of a given flavor
> rather than a Line2D for every single tick mark.
>
> There are two reasons this isn't a total win:
> 1) it's not done yet in all tick/grid configurations.
> 2) it loses flexibility in tick labeling
>
> The lost flexibility may matter a great deal to other people. In my
> use-case,
> the labeling flexibility simply seems misguided and the performance is much
> much preferred.
>
> Comments welcome about how this could move forward toward being included in
> MPL.
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> matplotlib-devel List Signup and Options
>