Re: [opendemo-devel] Perfomance.

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

Hello!

> > A ring-buffer would simply solve this bottleneck of constantly calling
> > fbGrow(), mbResize and memcpy() but we have 21 occurrences of
> > mbGetBuffer(),
> > whose are not so easily converted to a ring-buffer. We need to know before
> > calling mbGetBuffer(), how many bytes should be available. Maybe this is
> > already done with the usually fbGrow() call before mbGetBuffer() but I'm
> > not really sure in all 21 cases.
> If you put the ring-buffer code in od_filebuf.c instead of od_membuf.c (or
> add a middle layer), then that shouldn't be a problem. The fb* interface
> does not provide direct access to the buffer, so changing from linear to
> ring buffers shouldn't require other changes. mbGetBuffer() just gives you
> the start of the memory block (same as any other ring-buffer).
Almost correct. I thought mb* functions are used by fb* functions only but
that's not the case. Many others use mb* stuff too (and with it mbGetBuffer().
So we have to concentrate on fb* functions only.

But what is with xmlParseCharacters(), where we have the code:

        if (firstChar == -1) {
                if (doc.sax && doc.sax->ignorableWhitespace)
                        doc.sax->ignorableWhitespace(doc.userData,
                                mbGetBuffer(doc.fb->mb) + doc.fb->offset, len);
        }
        else {
                if (doc.sax && doc.sax->characters)
                        doc.sax->characters(doc.userData,
                                mbGetBuffer(doc.fb->mb) + doc.fb->offset + firstChar, len);
        }

This dissolves all the layering and gives a sax callback function direct access
to the (hopefully long enough) memory buffer.

I need to think about all this a bit more.

Bye, Uwe