Better yet, get something like True Time or VTune or other such performance testing tools. You'll be likely to find the low hanging fruit quickly and get the most bang per time spent. We used to use VTune pretty often on Xerces to find performance issues, and it massively improved in performance between the 1.1 and 1.2 code bases, if I remember correctly. I use VTune at work and at home and its great.
-------------------------- Dean Roddey The Charmed Quark Controller Charmed Quark Software [EMAIL PROTECTED] http://www.charmedquark.com "If it don't have a control port, don't buy it!" ----- Original Message ----- From: "Mark Weaver" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 03, 2001 4:59 PM Subject: RE: SAX performance observations > For string parsing a good approximation to best parsing can be provided by > using a hash table. You will only have to do comparisons then in the case > of collisons. Since your tags are fixed, careful choice of a hash function > and hash table size will mean that they at least don't coincide. If you can > guarantee that you only ever see these tags (e.g. you have validated the > document against a DTD), then you can construct a perfect hash function, > which will remove all collisions - GNU gperf is good for this. > > If you want to go one better then you can construct a DFA to recognise the > strings; DFAs can be generated by lex/flex (which you will have to hack on > quite a lot to support the unicode chars), or if you are feeling brave :-) > you can construct them by hand. Basically DFAs cut out comparison and > reduce everything to table lookups (speed gained at the expense of code > bloat). I got a good speed increase in a text parser of ~3X by recoding it > as a DFA. > > However - before you go overboard with this, are you sure that your parsing > speed problems still lie in the startElement handler/string recognition? > One easy way to tell: remove all "do somethings" and time. Remove all code > and time. Compare the two. If there is only a small percentage difference > then you are optimising the wrong code! > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
