Re: performance issues

From: Mike Nordell (tamlin@algonet.se)
Date: Sun Jul 21 2002 - 16:44:52 EDT

  • Next message: Hubert Figuiere: "Re: commit: fix #3582 and some revisions stuff"

    Joaquín Cuenca Abela wrote:

    > If we measure the cost of the operation in number of lines "reflowed",
    > we get:
    >
    > t: nb of lines in the document
    > n: nb of lines by page (approx.)
    > N: nb of pages
    >
    > t = n * N
    > cost = t + (t - n) + (t - 2n) + ... + (t - n * N)

    Holy Goat! That's BAD!

    What if... I'm going out on a limb here, but what if we instead of "pushing"
    lines back (onto the next page, repeat as needed) had a "virtual"
    document/layout that the on-disk document got loaded into (without any of
    the flowing calculations/calls taking place of course, that would be the
    "virtual" part of it) and then the layout engine instead "pulled" runs/lines
    from that virtual document to layout the stuff as needed?

    It would obviously be a tremendous speedup for the loading case, but would
    it work in the general case? I think so, but obviously this is an area where
    some redesign is needed why additional input can't hurt.

    > And a last note, the breakSection (the root of this problem) is
    > convoluted (>500 lines for a single function?).

    I used to be a maintainer of project inherited from a proprietary code-base
    and we found functions that were several _thousand_ lines long! Speak about
    unmaintainable. AW has a function a couple of hundred lines? Pffft. :-)

    No, seriously, a function that large is too large and should be refactored.

    /Mike



    This archive was generated by hypermail 2.1.4 : Sun Jul 21 2002 - 16:51:46 EDT