Re: how to estimate speed of a transformation

> > 
> > GC has little relation to optimizations advanced processors 
> > perform. 
> 
> This may be true in theory; however, from what I've heard and seen,
> people writing XSLT processors in languages without automatic garbage
> collection have had to spend an enormous amount of effort doing the
> memory management, effort which might otherwise have been spent on
> rewrite optimizations.
> 
> A processor written in C will be faster than a Java processor in the
> end, but only after you've written about 5 times as many lines of code;
> and even then, it will probably have memory leaks.

That can be an issue, but not as severe as 5 times difference in effort.
First, while writing manual memory management for C data structures in
the traditional way is a nightmare, implementing compressing mark-and-sweep
for a particular class of data structures, such as nodes, is easy.

Besides, there is a very efficient implementation of GC for C, and it is
proved to work for many applications. I mean Boehm's collector,
http://www.hpl.hp.com/personal/Hans_Boehm/gc/. If use of GC makes writing XSLT
processors so much faster, their authors should consider using it. By the way,
Hans Boehm, the author of the implementation and a  proponent of GC, estimates 
efforts devoted to storage managements as 30%-40%.

David Tolpin

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list