Re: XML/XSLT processing times

> 2. Linux cp command - 25 milliseconds.

this is possibly unfair (e.g. if done all in kernel space and returning
before it's really finished).

> 3. Gobo Eiffel XML parser using the example/xml/tree/formatter program
> (modified to operate in unicode string mode, as there were unicode
> character references in the XML file, and commenting out the DTD in
> the file, as the program will not process an external DTD) - 15
> seconds.

it would be interesting to check with a similar example with no unicode,
to see if we're hit by the unicode processing (which wouldn't surprise
me).

> 4. Gobo Eiffel XML parser using the example/xml/event/print program
> (same modifications as above). Output redirected to a file. - 26 seconds.
> 
> The last one was particularly intriguing, as I noticed half the time
> was kernel time. I redirected it to /dev/null instead and it came down
> to 10 seconds. I'm not sure what is going on at all here. Any thoughts?

hm interesting. a guess is that we may be feeding the output 1 character
at a time (you could check with strace) and the other side doesn't like
being fed that way (but it's not in the system call overhead as such, as
/dev/null has the same overhead). if it's the case, it's a bit
surprising (I'd have expected libc and/or the kernel to do buffering).

> ST_STRING might be useful anyway. Shall I post the classes here for
> review?

I'd say yes.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/