Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#158 1.95.3: xmlwf startup time much longer

Greg Stein
Rolf Ade

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.)



  • Logged In: YES

    Ugh! This is heinous! The crufty libtool wrapper should
    never be installed, and even says so itself.

    Greg, can you fix this soon?

    • labels: --> Build control
    • priority: 5 --> 7
    • assigned_to: nobody --> gstein
    • priority: 7 --> 6
  • Logged In: YES

    This is painful, but not enough to hold up a bugfix release.

  • Greg Stein
    Greg Stein

    Logged In: YES


    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.


  • Rolf Ade
    Rolf Ade

    Logged In: YES


    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.


  • Logged In: YES


    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?

  • Rolf Ade
    Rolf Ade

    Logged In: YES


    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.


  • Greg Stein
    Greg Stein

    • status: open --> closed-works-for-me
  • Greg Stein
    Greg Stein

    Logged In: YES

    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.