[fpc-pascal] msedb and fcl-db benchmarks

[Michael Van Canneyt]

On Tue, 17 Jul 2007, Martin Schreiber wrote:

> On Monday 16 July 2007 14.20, Joost van der Sluis wrote:
> > Hi all,
> >
> > To see what the differences in speed are between MSEdb and fcl-db I did
> > some benchmarks. (See the attachment for the code and results)
> >
> [...]
> 
> > I tried to explain the readdata-difference. At first I thought that
> > msedb converted all strings from string to widestring to string. But it
> > doesn't do that. (see my mails on this subject)
> >
> You are wrong here.
> "
> function tmsebufdataset.loadbuffer(var buffer: recheaderty): tgetresult;
> [...]
>      if field1.datatype in charfields then begin
>       int2:= int2*4+4; //room for multibyte encodings
>       setlength(str1,int2); 
>       if not loadfield(field1,pointer(str1),int2) then begin
>        setfieldisnull(buffer.fielddata.nullmask,fno);
>       end
>       else begin
>        if int2 < 0 then begin //buffer to small
>         int2:= -int2;
>         setlength(str1,int2);
>         loadfield(field1,pointer(str1),int2);
>        end;
>        setlength(str1,int2);
>        po2:= pointer(@buffer) + offset;
>        if bs_utf8 in fbstate then begin
>         po2^:= utf8tostring(str1);     <<<<<<<<<<<<<<<<----
>        end
>        else begin
>         po2^:= msestring(str1);     <<<<<<<<<<<<<<<<----
>        end;
> "
> msestrings.utf8tostring:
> "
> function utf8tostring(const value: utf8string): msestring; overload;
> "
> msestring = widestring.
> 
> > I think that the only reasonable explanation is the argument from
> > Michael: using ansistrings/pointers to store the data instead of storing
> > them directly into a buffer, induces so much overhead that it becomes
> > too slow.
> >
> > Overall, I would conclude that the current design of the TBufDataset of
> > fcl-db is a better choice then the design of tmseBufDataset. Since fcl-
> > db is faster on those things a TBufDataset is build/meant for: browsing
> > through records.
> >
> tmsebufdataset is designed to work well with the MSEgui visual components 
> where TBufDataset was not ideally suited.

Why not ? From what I can see, your only problem is the widestring issue, 
which we can solve as indicated in earlier mails. The reference count issue 
has nothing to do with TBufDataset...

My conclusion is that there is no reason why we should not merge the 2
implementations - provided we include the possibility for you to store
everything as widestrings, of course, and this should not be a problem.
 
> > Discussion: What tests could I do more? Is there something I overlooked?
> >
> To work with tmsqlquery you should use tmsestringfield.asmsestring and not 
> TField.AsString, otherwise the slow ansistring<->widestring conversion takes 
> place on every access. On Windows you should not use FPC 2.1.4+ because 
> widestrings are no more reference counted and heap based...

Since 2.0.4 will no longer be supported, this is something you will have
to take into account. As far as I know, the reason for not having
widestrings reference counted on Windows is that they must be COM 
compatible.

But first we should still check memory requirements.

Michael.