Re: performance issues

From: Joaquín Cuenca Abela (
Date: Thu Jul 25 2002 - 14:25:27 EDT

  • Next message: Joaquín Cuenca Abela: "Re: performance issues"

    On Wed, 2002-07-24 at 09:59, Joaquin Cuenca Abela wrote:
    > > we really only have one run per line of uniformly
    > > formatted text, runs
    > > are coalesced in every call to
    > > fl_BlockLayout::formatLocal(), and the
    > > code there, AFAICT works.
    > ok, formatLocal coalesces runs, but before that, we're
    > creating ~2 runs by word, and we're calling plenty of
    > PP_evalProperty due to that (which turns to do a lot
    > of calls to the hash, more than 20 millions).
    > We *create* 165382 runs in the document. Looking at
    > the code:
    > bool fl_BlockLayout::_doInsertTextSpan(PT_BlockOffset
    > blockOffset, UT_uint32 len)
    > {
    > [...]
    > while(len > curOffset - blockOffset)
    > {
    > [...]
    > for(i = 1; i < trueLen; i++)
    > {
    > iPrevType = iType;
    > iType = fribidi_get_type((FriBidiChar)pSpan[i]);
    > if(iType != iPrevType)
    > break;
    > }
    > xxx_UT_DEBUGMSG(("_doInsertTextSpan: text run:
    > offset %d, len %d\n", curOffset, i));
    > fp_TextRun* pNewRun = new fp_TextRun(this,
    > m_pLayout->getGraphics(), curOffset, i);
    > [...]
    > }
    > So we're creating a run each time fribidi type of a
    > character changes. English chars and spaces don't
    > have the same fribidi type, so at this point we're
    > splitting several runs.

    I've just tested that, replacing the if (iType != iPrevType) by if
    (false) (ie, _doInsertTextSpan will not split anymore textruns due to
    the fribidi char type).

    And as expected, the results are impressive: The most called function
    (UT_StringPtrMap::find_slot) changes from ~16 000 000 times (with my
    little optimizations, before it was >21 000 000), to ~3 900 000. And we
    have a reduction with the same fold on the others highly called
    functions (more or less all the functions in the top 20).

    With this change we open my big doc in just a bit more than 1/3 the time
    we took before. Of course, that still sucks, I'm pretty sure that we
    can easily do twice or three times faster, and after that I think that
    the patches will start becoming less trivial.

    Now, I don't know even nearly as well as Tomas the fribidi code. I
    don't know until which point we're doing low level stuff, and until
    which point we're delegating in fribidi. Tomas, can you think of a good
    way to change the

            iPrevType = iType;
            iType = fribidi_get_type((FriBidiChar)pSpan[i]);
            if(iType != iPrevType)

    into something correct that don't breaks spans on ltr text upon a space?

    Maybe should be ignore neutral characters and separators in the

    For those that got lost, reading a 205 pages document:
    before -> 2m40s
    after -> 40s

    (And I'm confident that we can bring that under 20s without any big


    Joaquín Cuenca Abela

    This archive was generated by hypermail 2.1.4 : Thu Jul 25 2002 - 14:31:14 EDT