#158 1.95.3: xmlwf startup time much longer
At least at my linux box, I seems that the new way of
starting xmlwf - with a shell wrapper - heavily
increases the startup time of xmlwf.
For most people, this may be a really minor problem (it
isn't even a big one for me, though). But if you check
a lot of really small xml files with xmlwf in one
commandline or a shell script, this is very notable.
I've noticed it, while checking the (very small) test
files of the OASIS test suite. My shell scripts, that
does this, needed up to 10 times (!) longer, to finished.
To be sure, it's really the startup time, I checked
xmlwf against some bigger XML files (around 30 Mbyte)
and found only minor speed differences between 1.95.2
and 1.95.3. It seems, 1.95.3 is around 6 or 7 percent
slower than 1.95.2 (I've substracted the mesured longer
startup time of the 1.95.3 xmlwf from the running time,
befor calculation.)
rolf
Logged In: YES
user_id=3066
Ugh! This is heinous! The crufty libtool wrapper should
never be installed, and even says so itself.
Greg, can you fix this soon?
Logged In: YES
user_id=3066
This is painful, but not enough to hold up a bugfix release.
Logged In: YES
user_id=6501
Rolf,
Was your slower time measured against xmlwf out of the build
tree, or an installed copy? As far as I can tell, we never
install the shell script wrapper. Within the build tree, it
will always be present (the first run will be slow while it
links, then it should be faster (but not as fast as without
the shell script, of course))
Anyways... we need to find out if your observation was for
the build or installed copy of xmlwf.
thx.
Logged In: YES
user_id=13222
Greg,
well, you got me. Yes, I observed the slowdown of xmlwf,
while running it from the build copy. Yes, after
installation, there isn't a shell wrapper anymore, just the
xmlwf binary. I'm sorry about any irritation, I've triggered.
But - not to distract from my mistake, but because I'm
really a bit worried about - even beside this shell wrapper
thing (which is not a problem, I confirm) expat is getting
slower and slower, from version to version. It's not
dramatic, but it sums up.
I've just done some tests, that confirmed that again. To
give some concrete numbers (on a linux 2.2.13, PII 333MHz,
384 MByte memory) from checking a around 100 MByte big XML
file with the according xmlwf tools (I ensured, that the
file is in the system cache)
With 1.92.3:
real 0m12.108s
user 0m11.360s
sys 0m0.660s
With 1.92.2:
real 0m11.152s
user 0m10.450s
sys 0m.670s
With James Clarks 1.2final:
real 0m9.471s
user 0m9.360s
sys 0m0.090s
This numbers are typical for all XML files, I've done this
comparson. To sum up the results, this is a solid 25 percent
slow down from 1.2 to 1.92.3.
Remarkable is the much greater sys part for the 1.92.x
versions. This may because of changed I/O code in the xmlwf
tool (haven't check this). But even without this, there's a
notable slow down.
It's not dramatic, as said. Expat is still the fastest
compliant XML parser, I know. But to say it frankly, one of
the major points of using expat (if not the major point) is
simply its speed.
Some slow down may be unavoidable (for example due to the
reasent fix for better detection of invalid XML chars), but
I would love, if someone checks this - and the speed of
current versions in general - with a critical eye.
rolf
Logged In: YES
user_id=3066
Rolf,
I think general slowdown is a separate issue from xmlwf
startup time, which appears to be either solved or a
non-issue at this point.
Would you be interested in doing some "regression
benchmarking" and possibly gathering profiling data to see
what portions of Expat are exhibiting the most change?
Logged In: YES
user_id=13222
Fred,
you're of course right, the general slowdown is a seperate
issue. I'll open a seperate bug report for this.
To confirm this cleary, the xmlwf startup time is definitely
a non-issue (there was nothing to solve, right from the start.)
I just not noticed that. This time, my habit, to test
software, befor I install it system wide has bitten me :-(.
Again, sorry for any wasted time.
rolf
Logged In: YES
user_id=6501
No worries... I don't feel you wasted my time. And the
testing, commentary, suggestions, etc that you've provided
are definitely appreciated!
Closing this issue.