Re: [xep-support] XEP Performance Questions

From: Werner Donné (
Date: Fri Jan 03 2003 - 07:59:24 PST

  • Next message: Jarrod Stenberg: "Re: [xep-support] XEP Performance Questions"


    I fear your example, one page, is not representative and can't provide
    accurate figures about performance, because the proportion of the JVM
    launch overhead is too large. When XEP is used as a server component the
    overhead could be ignored.

    The JVM choice is, in my opinion, not going to produce dramatic differences,
    unless you can find some very specialised JVM. It also depends on the situation.
    For a configuration as a server component, maximal pre-compilation is an
    advantage for example.

    Regarding architecture I would propose an asynchronous interface to such a
    heavy processing component as an XSL-FO formatter. You can compare it to
    report generation. This will be better for scalability and it will keep
    resource usage under control by tuning the level of concurrency. Thus, the
    question becomes how much requests can be handled at one point in time instead
    of how long a request takes to process.

    To end maybe a reflection on the performance perception itself. To evaluate if
    XSL-FO formatting is slow or fast in general we need to compare it to something.
    For authored document processing I would compare it to systems such as TeX. For
    reporting it can be compared to classic report generation. I think in both cases
    there is nothing to be ashamed about for the XSL-FO technology. Authored document
    processing is perhaps too easily compared to WYSIWYG document processing and then
    one is faced with this "extra" processing step. The comparison is, however, not
    correct because the approach is entirely different. It should also be stressed
    that XSL-FO is used for fine printing, while WYSIWYG technology mostly doesn't
    go beyond draft printing quality.



    Jarrod Stenberg wrote:
    > XEP users and developers:
    > I have been working with a copy of 2.78 for an
    > academic client. I am running RedHat 7.2 (2.4.3) on a
    > dual proc PII 800 MHz with 768 Megs of ECC RAM. The
    > JVM:
    > Java(TM) 2 Runtime Environment, Standard Edition
    > (build 1.3.0)
    > Classic VM (build 1.3.0, J2RE 1.3.0 IBM build
    > cx130-20010626 (JIT enabled: jitc))
    > Note: I am not validating the XSL-FO. I find that
    > rendering is on the slow side. For example, I am
    > rendering a page that has nested tables (1 level deep)
    > and one graphic (seems to have little to no effect
    > when removed) which takes about 5 seconds to render.
    > If I take the nested table out, I get an increase of
    > almost 2 seconds. I know performance is a common
    > complaint with today's XSL-FO rendering engines. I am
    > willing to live with it to some degree, but crave a
    > bit more speed. I have searched and have been unable
    > to find any claims about the speed of versions 3 and
    > greater. Is it better? Will future versions address
    > speed? If so, how soon? Please point me to any
    > information on this matter. Also, I have read on your
    > support archive site about certain JVMs being faster
    > than others, but the respondants failed to say which
    > flavors. Which JVM performs the best?
    > I have a client with deep pockets who is considering
    > moving to XSL-FO with its next generation of ASP
    > solutions. I need to have meeting fodder on the topic
    > of performance. Deep pockets also means they may be
    > willing to spend a bit on better servers than my
    > academic client. So I may be able to muscle through
    > it for now. Also note, this client will be dealing
    > with larger, more complex documents.
    > Thank you for any thoughts on the matter.
    > -Jarrod Stenberg
    > P.S. Great product overall! I think XEP has made
    > XSL-FO viable in the present.
    > __________________________________________________
    > Do you Yahoo!?
    > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
    > -------------------
    > (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    > in the body of the message to from the address
    > you are subscribed from.
    > (*) By using the Service, you expressly agree to these Terms of Service

    Werner Donné  --  Re BVBA
    Engelbeekstraat 8
    B-3300 Tienen
    tel: (+32) 486 425803	e-mail:
    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service

    This archive was generated by hypermail 2.1.5 : Fri Jan 03 2003 - 07:54:17 PST