Subject: Re: [xsl] how to estimate speed of a transformation From: David Tolpin <dvd@xxxxxxxxxxxxxx> Date: Fri, 12 Dec 2003 16:39:57 +0400 (AMT) |
> > > > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] how to estimate speed of , Michael Kay | Thread | [xsl] Re: Re: Unbounded element gro, Dimitre Novatchev |
[xsl] Re: Re: Re: Re: Re: Unbounded, Dimitre Novatchev | Date | Re: [xsl] how to estimate speed of , David Tolpin |
Month |