On 13 Oct 2000, Lars Gullik Bjønnes wrote:
> And the idea to use strings in these places is not really new, either.
> IIRC the last proposal to use XTL was more or less a direct reaction to
> this idea, based on the (unvalidated and IMNSHO unjustified) assumption
> that using strings might be too slow.
Notice that stream_cast and XTL does NOT solve the problem in the
same way.
stream_cast is a neat thing, but it is inefficient compared to XTL.
I haven't done any measurements, but I would not be surprised if it
was 50 times slower than XTL, simply because it takes time to parse a
string. XTL has about 10%-20% overhead compared to a memcpy. You don't
get faster than that.
I agree that for LyXFunc, this is not an issue at all. stream_cast could
be 500 times slower, and it still wouldn't matter, since it's not a
critical code path in any way. I don't think anybody ever said that.
However, the main advantage of XTL is not speed, but simplicity.
With XTL, you only have to write ONE serialization function that
works for both read/write.
With stream_cast (and all other schemes I have seen), you have to
write separate functions for reading and writing of data.
The disadvantage is that the code is twice as big in the source,
and that you risk getting out of synch. Also, it's double the work to
change any structures in your code.
Another great difference is that XTL is naturally recursive. You can
conceptually stream the entire LyX document data structure with one single
function call. All you need to do is to define the streaming function for
each structure in your code, and you will automatically get the entire
streaming for free. This works even if your data-structure is a graph
which contains "endless" loops. All you have to do is to ask for the data
structure to be streamed. Notice that you don't have to do anything
special to stream out pointers, arrays or other structures.
In the stream_cast case, you have to manually construct streaming
functions for both reading and writing of all your structures, but ALSO
for all containers, pointers and so on. Furthermore, you can not simply
stream a data-structure that contains loops. You have to manually take
care not to enter an infinite loop.
Another advantage of XTL is that the underlying data format can be changed
with a one-line patch. In this way, it is extremely easy to support many
different formats of the same code. In particular, you can be using some
RFC standards for data interchange, rather than you own home-brewed text
format.
Finally, since XTL can avoid doing any conversions of your data, there is
obviously minimal memory overhead.
When all of that is said, the problem with XTL is that it is not portable
enough yet, so it's not suitable for usage in LyX at this point. We tried,
and failed. So that's the end of that discussion so far. We have to wait a
few years until compilers catch up.
Meanwhile we have to chose something else. In this context, stream_cast
seems like a good choice.
stream_cast is a neat construct to lever the existing parsers in the
streams in the standard library. That's it. It solves only one problem
in the context of streaming data structures.
Please don't say that string_cast is technically superior to XTL. That is
simply not true.
I just thought that I would clarify things a bit.
Greets,
Asger
