Re: [opendemo-devel] Perfomance.

[Dr. U. G. <Uwe...@ph...>]

Hello!

> ... As expected, the bottleneck is XML parsing, which is not surprising,
> lots of strcmp's in odpStartElement().
But not all will be used every time. Therefore the parser keeps its state and
does only some strcmp()s every time. I'm thinking about a hash but I really
suspect, that it should be a lot faster.

> Second function that takes much time is fbGrow(),
> third in a row is fbReadChar().
And mbSize().
This is all somehow connected:

size_t
mbSize(mb_t* mb)
{
        return mb->size;
}

There is nothing to optimize any more, so we have to use inlining or a
macro for this function.

The same holds true for
char*
mbGetBuffer(mb_t* mb)
{
        return mb->base;
}

I think these two functions should be replaced by macros.

>         Func          Func+Child           Hit
>         Time   %         Time      %      Count  Function
> ---------------------------------------------------------
>      339,888  14,3      342,367  14,4    10816 _odpStartElement (odp_parse.obj)
>      328,374  13,8      809,179  34,1   870447 _fbGrow (od_filebuf.obj)


>      302,485  12,8     1231,081  51,9   666036 _fbReadChar (od_filebuf.obj)
This is the main bottleneck!!!!!
fbReadChar() calls fbGrow(), mbSize() (should be a macro) and mbGetBuffer()
(should be a macro too).
fbGrow() calls mbSize() again.

>      245,019  10,3      245,019  10,3  1795349 _mbSize (od_membuf.obj)
>      168,478   7,1      168,478   7,1  1173068 _mbGetBuffer (od_membuf.obj)
>      148,394   6,3      148,394   6,3   390172 _trap_FS_Read (g_syscalls.obj)
>      115,466   4,9      263,860  11,1   390172 _odFread (od_q3a_fileio.obj)
>       91,773   3,9      145,829   6,1   173056 _odpUpdateEntity (odp_main.obj)

>       73,557   3,1      868,949  36,6    29724 _xmlParseName (od_xml_read.obj)
from the source:
        c = fbReadChar(doc.fb, 0);
this line is totally useless

check of the first character
        if (!IS_NAMESTARTCHAR(fbReadChar(doc.fb, 0))) {
                doc.errNo = XML_ERR_NAME_REQUIRED;
                doc.errString = "Name does not start with valid character";
                return NULL;
        }

this checks for the end but does not remember the characters
        for (len = 1; ; len++) {
                c = fbReadChar(doc.fb, len);

                if (!IS_NAMECHAR(c) || c == EOF)
                        break;
        }

now we allocate enough space
        name = (char *)odMalloc(len + 1);
and read the full name AGAIN
        fbRead(doc.fb, name, len);
        name[len] = '\0';
I think we should collect the characters in a local variable and simply copy
them over after odMalloc(). fbRead() calls fbGrow() and 2 times mbSize(),
no wonder that it takes so much time.

>        0,776   0,0     2370,985 100,0      321 _vmMain (g_main.obj)
just as expected. Your profiling tool can sum up accurately!

>        0,144   0,0     2238,701  94,4      168 _odpReadSnapshot (odp_parse.obj)
That is interesting. Most of the time, we have snaphosts. Maybe a simple
reordering of the strcmp()s by the number of their appearance would help
a lot.

I'll try to add a new profiling target to the Makefile to help profiling
under Linux (using gprof).

Bye, Uwe