Re: Re: Bundling libxml2 and expat compatibility layer

Hi Sterling, > Have you tried and compared? How do you know your right? A well > written hand lexer will always be faster. Not only has it been shown > (python, for example uses a custom coded scanner for speed), but it > makes logical sense. First, flex builds LFA trees, which will always be > slower matches then a custom built matcher. Second, flex can't be as > intelligent about buffer handling as a custom parser could be. Okey. You arguments make sense. Unfortunately, I don't see good performance form libxml2. Let I make myself as clear as ever possible. I have my own library that builds xmldom. It's not very efficient and was written in one-two days so finally I was never satisfied with it. I had no time neither to rewrite nor to optimize it and I was always thinking about a good replacement. When I tried libxml2 I was deeply impressed. Let I compare the final results: operation my library libxml2 parse xml from file 177ms 267ms parse xml from memory 172ms 786ms free xml doc 18ms 133ms I know (BELIEVE ME that I know) my library is not efficient. That's why I was wondered with libxml2 results and started learning why. When I traced through all libxml code involved in parsing document I found many elementary pitfalls and concluded some ideas which I finally descibed in my messages posted at this forum. You said one great thing "A well written hand lexer". That's not the case. > Anyhow, this is offtopic, let it die. OKey. Let it die. That were my last arguments. All the best, Dmitri.