tick marks and render speed

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:

  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

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
https://github.com/matplotlib/matplotlib/issues/347 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 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
>
>
> ------------------------------------------------------------------------------
> 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
>