Seems OK to me too. Even if the Tidy implementation is not being used in anger, it think it could be useful to have it available as a cross-check.
Looks like Tidy did at least improve its performance using the recursive scanner. == By the way, does anyone know which version of Tidy is being used - and where the Tidy.jar came from? The classes in the jar were compiled on 11/06/2002, and Tidy.jar is dated 13/06/2002. The latest JTidy zips on SF seem to date from August 2000, and there don't seem to be any pre-built jars. == If the Tidy parser was known to be thread-safe, it might be possible to improve performance by re-using the parser (but not the DOM - that would be cheating!) S. -----Original Message----- From: peter lin [mailto:[EMAIL PROTECTED] Sent: 26 November 2003 19:59 To: JMeter Developers List Subject: Re: Parser performance tests, some conclusions, some questions thanks for running those tests. interesting results and good food for thought. unless we are in a hurry to release the next version I am planning on debugging htmlparser and figuring where the bug is. the code for the images should be isolated in 2 classes, so tracking down the bug should be straight forward. unfortunately I won't have time until friday/saturday at the earliest. We can continue to use JTidy as the default until I fix Htmlparser. does that sound reasonable? peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
