03/18/2004 12:48 cc
PM
Subject
RE: SAX v DOM speed
> Why don't you simply comment out your code in the event
> handlers, and see
> what the performance is like? If the parsing has reached a
> speed close to
> what you would expect, you can introduce your code bit-by-bit
> or profile it
> to see where the problems are.
yeah I can do that
The r
; From: Gareth Reakes
> [mailto:[EMAIL PROTECTED] Behalf
> Of Gareth Reakes
> Sent: 18 March 2004 17:10
> To: [EMAIL PROTECTED]
> Subject: RE: SAX v DOM speed
>
>
> Hi,
>
> > I copy the data into a vector of chars and set a variable
> > the vector is only ever
ts for SAX and DOM may not be the same.
>
> George
>
> Begin forwarded message:
>
> > From: "Vincent Finn" <[EMAIL PROTECTED]>
> > Date: March 18, 2004 10:21:17 AM EST
> > To: <[EMAIL PROTECTED]>
> > Subject: RE: SAX v DOM speed
> >
> That's what I was expecting. That's what worries me
>
> I don't do much in the events.
> I copy the pointer for element names and the string for text
> and a small bit of management to make sure there are no leaks or other
nastiness
> I am doing a progressive parse but I wouldn't have thought
Hi,
> I copy the data into a vector of chars and set a variable
> the vector is only ever cleared (not fully released)
> so once the memory has been got once it will remain available for the next time
Do you add the data 1 character at a time? If so that is potentially a
very large amount of vect
t(--m_acData.end(), &pcText[0], &pcText[uiLength]);
}
m_pcData = &m_acData[0];
m_LastEvent = eventTextElement_e;
//
> -Original Message-
> From: Gareth Reakes
> [mailto:[EMAIL PROTECTED] Behalf
> Of Gareth Reakes
> Sent: 18 March 2004 15:08
> To:
Hi,
You can view the creation of the DOM Tree as a sort of SAX parse that
creates the objects that are required. If you are not doing any heavy duty
work in the methods you have overriden I would expect it to be
significantly faster.
Gareth
--
Gareth Reakes, Managing Director+44-186
