Hello,
Other than some platform-specific issues (like the Mac) there are some
general performance issues which I'm going to list here so we have a
record in one spot. Hopefully as time goes on some of these issues will
be better understood and sorted.
(1) There are too many redraws happening. So when something changes
instead of drawing it once it sometimes (or often) draws it N times where
N can be (say) 6. We have code in place so that the drawing happens
"after_idle" (in the Tk jargon) and check that a refresh is really needed.
If it wasn't for that we might end up with 10*N redraws. But even the
after_idle doesn't seem to stop extraneous redraws. This whole problem is
complicated by the fact that drawing is driven by the Python world
although most of it happens in the C world. I suspect that some of the
slowness is inherent with this after_idle approach.
(2) There are memory leaks. They could be in our C code (although that
has been checked to some extent). But we're fairly certain there are some
Tk (well Tkinter) widget memory leaks, which we can probably work around
when we figure out exactly where they all are. (Likely candidates include
menus, since they are often created on-the-fly.) Although the widgets
themselves don't perhaps take much memory up directly, they can hold
references to other Python objects which then never get garbage collected,
and that starts to add up. The only current workaround for this is to
stop the program and start again.
(3) The contouring happens on-the-fly. The data for this is cached. But
if you have gigabytes of data you will run into trouble, because it cannot
all be cached. And if your data is accessed over a slowish network this
will make the problem worse. Ansig got around this by having pre-computed
contours. In the next release of Analysis we are going to allow
pre-computed contours to be used (instead of or as well as on-the-fly
ones). Of course the problem with pre-computed contours is that they have
fixed contour levels, so you cannot wizz up and down the level. This is a
typical tradeoff between functionality and speed. And for on-the-fly
contouring it is bound to help if you can keep your data on a local disk.
(4) All the so-called metadata (i.e. data about your data) is stored in
Python objects. In particular peaks are. If you have a million peaks
(which can easily end up meaning 10 million objects) you are mostly likely
going to have a performance problem. We have spent some time trying to
optimise parts of the Python code to make this less of a problem. But
Python is not C, even though they claim there are speed improvements with
each release of Python. In addition, the peak information is partly
repeated in the C world (so that they can be drawn), although in a more
memory-efficient way. (We were looking into manipulating the Python peaks
directly in the C world to cut down on this extra memory use but it made
the performance too horrible.)
Wayne
|