CairoPlot related Project
87 views
Skip to first unread message
Magnun Leno
Jul 10, 2012, 12:28:30 AM7/10/12
to CairoPlot
Hello everybody from CairoPlot mailing list,
In the last weeks I've read some articles that made my brain go
psycho (I even forgot about my post-graduation thesis which is due to a
couple of months, I'm sorry). After some days of unstoppable research,
study and coding I came up with something that might be (or not) very
useful for the community. But before anything I must say that I got a
little disappointed with the results.
In short, I've written a C (a shared library) port of CairoPlot and
a Python Binding that I've called ccairoplot (in order to avoid any
conflict with the pure python cairoplot module). Currently it only
supports the horizontal bar plot with some options (rounded border,
margins and grid) and can generate outputs in png and svg. It was a
really straight forward experience in which I've tried to achieve the
same aesthetic standard defined by Rodrigo. This is the compared result[1].
Now the sad part. After some test I haven't achieved a significant
speed improvement as expected. I've written a python test script which
plots 50, 100 and 500 charts, each one with 10, 100 and 300 bars. These
are the results:[2][3]
As you can see, with small values (50x10, 50x100, 100x10, 500x10)
there is a really small improvement (a reduction of 10% or less in the
plotting time). I only achieved a significant speed improvement (close
to 25%) when using big data. Although, I still think that a C
implementation would be beneficial (no only for the Python community)
but for the Open Source as a whole, since the C implementation would
allow bindings for all other languages.
Since this is in a very early development stage the code is (a
little) crappy, undocumented and contains some memory leaks (according
to valgrind), and because of this it still live only on my Hard Drive.
By the way, I've used glib-2.0 (in order to reduce development time) but
in favor to cross-platform I intend to remove this dependency really
soon. Maybe all this aspects together are affecting the performance as a
whole (specially glib which is really huge and a little bloated).
And now I may ask you all: In this community, is there any interest
to keep this project and help it grow? If I remember well, Rodrigo once
said that he probably wouldn't involve himself in a C port of CairoPlot,
so I'm expecting to run this project completely independent from the
original python code which I'll use only and exclusively as a source of
inspiration and pattern guidance.
Despite any possible answer I'll push the source code to GitHub
soon, but I'll wait for the community support in order to use or not the
CairoPlot name. Nevertheless, I've already thought about an alternative
name (just in case). I really believe that this community (and many
others) will back me up, since this is a great project which must be
expanded for all possible languages.
If someone wants to take a look at the code, just ask me and I'll
send a .tar.gz containing the demo code and the build/test script. Now
I'm going to take a rest 'couse I'm at a caffeine outage and my brain is
already at terminall stage.
[1]: http://www.mindbending.org/files/2012/07/hbar-compare.png
[2]: http://pastebin.com/ThLR2AJF
[3]: http://www.mindbending.org/files/2012/07/bench.png
Magnun Leno
------------------
Blog: http://www.mindbending.org
Twitter: http://twitter.com/mind_bend
Google+: http://plus.google.com/b/102063745956138544914/
Facebook: http://www.facebook.com/MindBendingBlog
In the last weeks I've read some articles that made my brain go
psycho (I even forgot about my post-graduation thesis which is due to a
couple of months, I'm sorry). After some days of unstoppable research,
study and coding I came up with something that might be (or not) very
useful for the community. But before anything I must say that I got a
little disappointed with the results.
In short, I've written a C (a shared library) port of CairoPlot and
a Python Binding that I've called ccairoplot (in order to avoid any
conflict with the pure python cairoplot module). Currently it only
supports the horizontal bar plot with some options (rounded border,
margins and grid) and can generate outputs in png and svg. It was a
really straight forward experience in which I've tried to achieve the
same aesthetic standard defined by Rodrigo. This is the compared result[1].
Now the sad part. After some test I haven't achieved a significant
speed improvement as expected. I've written a python test script which
plots 50, 100 and 500 charts, each one with 10, 100 and 300 bars. These
are the results:[2][3]
As you can see, with small values (50x10, 50x100, 100x10, 500x10)
there is a really small improvement (a reduction of 10% or less in the
plotting time). I only achieved a significant speed improvement (close
to 25%) when using big data. Although, I still think that a C
implementation would be beneficial (no only for the Python community)
but for the Open Source as a whole, since the C implementation would
allow bindings for all other languages.
Since this is in a very early development stage the code is (a
little) crappy, undocumented and contains some memory leaks (according
to valgrind), and because of this it still live only on my Hard Drive.
By the way, I've used glib-2.0 (in order to reduce development time) but
in favor to cross-platform I intend to remove this dependency really
soon. Maybe all this aspects together are affecting the performance as a
whole (specially glib which is really huge and a little bloated).
And now I may ask you all: In this community, is there any interest
to keep this project and help it grow? If I remember well, Rodrigo once
said that he probably wouldn't involve himself in a C port of CairoPlot,
so I'm expecting to run this project completely independent from the
original python code which I'll use only and exclusively as a source of
inspiration and pattern guidance.
Despite any possible answer I'll push the source code to GitHub
soon, but I'll wait for the community support in order to use or not the
CairoPlot name. Nevertheless, I've already thought about an alternative
name (just in case). I really believe that this community (and many
others) will back me up, since this is a great project which must be
expanded for all possible languages.
If someone wants to take a look at the code, just ask me and I'll
send a .tar.gz containing the demo code and the build/test script. Now
I'm going to take a rest 'couse I'm at a caffeine outage and my brain is
already at terminall stage.
[1]: http://www.mindbending.org/files/2012/07/hbar-compare.png
[2]: http://pastebin.com/ThLR2AJF
[3]: http://www.mindbending.org/files/2012/07/bench.png
Magnun Leno
------------------
Blog: http://www.mindbending.org
Twitter: http://twitter.com/mind_bend
Google+: http://plus.google.com/b/102063745956138544914/
Facebook: http://www.facebook.com/MindBendingBlog
Rodrigo Araújo
Jul 10, 2012, 5:37:05 PM7/10/12
to CairoPlot
Hi there Magnun!
These are awesome news! A port of CairoPlot in C would really make it a lot easier for other languages to expand the project.
But (there's always a catch), as you said, I don't have the means to move the project to C as I've never even used it. I've only used C++, which is somehow similar, and even at that I didn't feel too comfortable.
So, I pretend to continue updating the CairoPlot Python branch but I'll gladly support CCairoPlot. If you ever need support on getting the right looks on the C version, I'm here to help.
Commenting on your benchmarks, as the pycairo lib is already a port of the Cairo lib, I believe the source of the improvements are the way you generated the values to plot (10, 100 and 300) as the speed gain of the C port only gets evident when the values are increased, but not when the number of plots are.
Also, it's interesting to notice how the time spent seems to increase linearly with the number of plots for all three options. The results, for example, for the pure python version (0.889, 1.774 and 8.877) scale almost by the same factor as the amount of plots (50, 100 and 500).
Such a simple correlation can't be noticed on the increase of the number of values.
So, as I said, I'll do my best to help you out and, at least from me, you won't see any resistance to use the CCairoPlot name.
Best regards,
--
Rodrigo Araujo
P.S.: bonus points for plotting the benchmarks using CairoPlot :D
These are awesome news! A port of CairoPlot in C would really make it a lot easier for other languages to expand the project.
But (there's always a catch), as you said, I don't have the means to move the project to C as I've never even used it. I've only used C++, which is somehow similar, and even at that I didn't feel too comfortable.
So, I pretend to continue updating the CairoPlot Python branch but I'll gladly support CCairoPlot. If you ever need support on getting the right looks on the C version, I'm here to help.
Commenting on your benchmarks, as the pycairo lib is already a port of the Cairo lib, I believe the source of the improvements are the way you generated the values to plot (10, 100 and 300) as the speed gain of the C port only gets evident when the values are increased, but not when the number of plots are.
Also, it's interesting to notice how the time spent seems to increase linearly with the number of plots for all three options. The results, for example, for the pure python version (0.889, 1.774 and 8.877) scale almost by the same factor as the amount of plots (50, 100 and 500).
Such a simple correlation can't be noticed on the increase of the number of values.
So, as I said, I'll do my best to help you out and, at least from me, you won't see any resistance to use the CCairoPlot name.
Best regards,
--
Rodrigo Araujo
P.S.: bonus points for plotting the benchmarks using CairoPlot :D
Magnun Leno
Jul 10, 2012, 6:25:04 PM7/10/12
to cair...@googlegroups.com
On 10/07/2012 18:37, Rodrigo Ara�jo wrote:
> These are awesome news! A port of CairoPlot in C would really make it a lot easier for other languages to expand the project.
Glad to hear that, especially from you.
> These are awesome news! A port of CairoPlot in C would really make it a lot easier for other languages to expand the project.
> But (there's always a catch), as you said, I don't have the means to move the project to C as I've never even used it. I've only used C++, which is somehow similar, and even at that I didn't feel too comfortable.
> So, I pretend to continue updating the CairoPlot Python branch but I'll gladly support CCairoPlot. If you ever need support on getting the right looks on the C version, I'm here to help.
project (since I really suck in aesthetics :D)
> Commenting on your benchmarks, as the pycairo lib is already a port of the Cairo lib, I believe the source of the improvements are the way you generated the values to plot (10, 100 and 300) as the speed gain of the C port only gets evident when the values are increased, but not when the number of plots are.
(but forgot to mention). But I really believed that the buch of if,
else, fors, enumerate, slicing (and etc) found int the pure Python code
was causing more performance degradation. I was sad to see that my
effort didn't rewarded me as expected but I was very happy (since I'm a
Python fan) to testify that Python can be almost as performatic as C.
> Also, it's interesting to notice how the time spent seems to increase linearly with the number of plots for all three options. The results, for example, for the pure python version (0.889, 1.774 and 8.877) scale almost by the same factor as the amount of plots (50, 100 and 500).
>
> Such a simple correlation can't be noticed on the increase of the number of values.
> So, as I said, I'll do my best to help you out and, at least from me, you won't see any resistance to use the CCairoPlot name.
repository link soon.
> P.S.: bonus points for plotting the benchmarks using CairoPlot :D
couldn't get this idea out of my head. My makefile have a Python script
that reads a json file and plots a bunch o charts before rendering the
LaTeX PDF. Also this is another idea of mine, write a CLI program to
plot graphics with CairoPlot. But that's another story...
Now let's see what others from the mailing list think about the
ccairoplot and how many are willing to help.
Reply all
Reply to author
Forward
0 new messages