Larry Loen wrote:
FlexRadio - Eric wrote:
I don't think there will be any significant performance hit due to using
XML.
Here we
are, living in a regime where we can barely make CW paddling work as it
is, and we want to burden our slowest path with this?
It would be more of a worry if the problem with CW were CPU load. It isn't.
Data representations,
I've found, are far more immortal than code.
Indeed. That's why the update command structure for the DSP under Linux
has been the way it is for something approaching two years.
Right now the overhead associated with a single update command to the
Linux DSP is a little under 3usec on a 1.2GHz machine. That number can
already be trimmed by batching the updates. There are also three other
critical spots in the update code that can be improved merely by
changing the associated algorithms -- no change in the protocol -- but
which have not been necessary yet. For example, the actual command
dispatch uses a linear table lookup. Dumb but simple. If the command set
grew much more, an obvious step is to replace the table lookup with a
perfect hash. This is a detail. Knuth: "Premature optimization" etc. etc.
Compare that 3usec with the ~1msec delay associated with executing a
*single* hardware command. That delay is imposed by the hardware.
There's a lot of room between 1kHz and 333kHz before starting to get
worried. In any practical sense you could already stream update commands
over FireWire.
But even then, in most uses I see, XML data flow does not dominate
execution in the way this well might...
There are advantages to being able to exploit both DOM and SAX models.
But in any case I don't think anybody is proposing to base the lowest
levels of execution on SAX callbacks. The idea all along has been to
provide a translation layer (which therefore is amenable to either DOM
or SAX) producing command streams at the simpler lower protocol level.
Furthermore it's been clear for at least two years that there is a
tradeoff between control rates and human perceptual limits. When it
comes to scrolling frequency, there is a ~20ms limit on how fast you can
even control your muscles on the mousewheel, playing against a ~10ms
threshold on how fast your ear can actually detect transient changes.
There is *no point* in changing gross controls faster than that.
Therefore the idea has been to apply, just as emacs does when updating a
text window, a dynamic program to the control stream, on the fly, to
optimize the data actually sent to the executing code and devices. The
command structure can consume data a lot faster than you can control it.
The job will be to thin the stream, not speed it up.
The overhead gobbled up in parsing an XML control stream is lost in the
noise. There is no foreseeable argument against XML that actually
applies to this situation.
73
Frank
AB2KT
