On Tue, 2007-07-17 at 09:40 +0200, 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;
Ah, that could explain the long fetch-times. I'll investigate this. > > 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. > > > 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... I'll change that. And I'm unsing linux. Regards, Joost. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
