On 26.07.05, Eugene M. Minkovskii wrote:
> Yesterday I read about your grahp module and thinking following:
> 1) PyX is a very flexible and powerfull instrument, because it
> based on the PostScript language and TeX.
> 2) graph is a very useful and simple to use instrument
> But there are some "spoon of wood-tar in the barrel of honey"
> (This is russian idiom)
> 3) PyX working very slowly. If I need the quick method to produse
> diagram, I forced to use PIL, not a PyX, because PyX delegate
> some parts of wor to lagre external programs.
PyX shouldn't be very slowly. Its not at all fast, right. And there
are areas, where PyX is slow in the sense, that we could improve the
speed at a later point (for example the binary reading of the dvifile
stuff is really slow ... try to process a 100 page dvifile by the
dviconvert.py as its distributed in the contrib directory ... this
is very slow). But for usual tasks, when the data to be plotted isn't
exactly huge, the speed should be reasonable.
Sometimes we observe slow behaviour due to a not optimal configured
kpathsea search. Usually we only use TeX as an external program and in
optimal configuration PyX never needs to start TeX several times (even
when creating several output files one after the other). Another
problem arises from using kpsewhich, when you don't compile the
pykpathsea extension module (but you should do that). This creates a
lot of system calls, right (and in 0.8 we have a problem that this is
extrodinarly slow due to a code reorganisation we did, but this is
already solved in CVS and should be released in a 0.8.1 soon).
Beside that I'm totally aware, that PyX isn't speedy at all. It
usually takes a second or so to process an typically complicated graph
... but that's reasonable having in mind the work which is done. For
example, the automatic axis partitioner calculates several possible
axis partitionings and some of them are then even typeset using TeX to
measure the distance between the labels. (We take that into account
when rating the partitions ... but you could for example disable that
feature ... and this might reduce the processing time for an average
graph by some ??? percent (I've never tried it).) A manual axis
partitioning (using graph.axis.parter.lin for example) will save you
all the rating feature completely, but than you have to do something
Overall the design of PyX is optimized to speed. And it will never be.
We do build up everything in memory and do not write PostScript at the
moment we're inserting something into a canvas, for example (as other
projects to it). This has some advantages: you can write a single
script, which create several files for example, and write the files
into single combined document and *at the same time*. You don't need
to take care of the bounding box, since it is calculated out of the
material to be written to the output files ... but this means a lot of
bookkeeping etc. This makes PyX convenient for the problems we want to
address with PyX. But it makes PyX slow, because it does what it has
to do. Those things are cpu and memory consuming.
And once you want to create a raster image, you need to rasterize
everything in the end. This is also a cpu and memory consuming
> Perhaps you can improve some in the PyX, but I can't belive that
> you can make PyX as speedly as PIL.
PIL is fast only as long as you make heavy use of the C parts of it.
But once you start to program some time consuming stuff on top of it,
the whole thing will be slow as well. For example: when we would
stroke our paths into a bitmap instead of writing the information to a
file, we would create a pixel image ourself, but this would even take
much additional time, since writing something like "10 20 lineto" into
a file is certainly a fast way to draw a line.
> And I think it's right: PyX
> good for vector graphic, and PIL for raster.
> I dream about some UpLevel driver for PIL which have interface
> same as PyX. With this driver programmer will can abstract from
> the PyX or PIL and wrote something like:
> from pyx import graph
> except ImportError:
> from dream import graph
> Or, more wise:
> def getpicture(format, *args):
> if format in ["EPS", "PDF"]:
> driver = pyx.graph
> driver = dream.graph
> ... implementation, which use driver
> What do you think about? Prehaps I don't know something and this
> already done by somebody, perhaps I should be write this "PIL
> emulator", perhaps this may be part of the PyX.
As I said, this will not at all speed up things. That's the problem.
In case you need a speedy way to create a graph, for example, you
could look for something else like gnuplot. This is certainly a more
appropriate tool for some tasks you might be interested in ... it's
just much faster for certain tasks. But PyX doesn't really compete
with it. It has other strengths ...
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/